Parag Mali - tag: kql

One Event, Three Portals: How a Single Sysmon Line Becomes a Microsoft Defender XDR Incident

noreply@paragmali.com (Parag Mali) — Thu, 04 Jun 2026 00:00:00 GMT

A single Sysmon ProcessCreate event takes six observable hops to land in a Microsoft Defender XDR incident: kernel ETW emission, agent shipping through a Data Collection Rule, ingestion into a Log Analytics workspace, KQL detection in Microsoft Sentinel, optional alert correlation from Microsoft Defender for Cloud's CWPP plans, and finally entity-graph fan-in inside the unified Defender portal [@ms-learn-sysmon] [@ms-learn-ama-overview] [@ms-learn-mdc-xdr-concept] [@ms-learn-xdr-correlation]. Each hop adds latency, loses fidelity, or introduces a configuration cliff -- and one wrong word in a Data Collection Rule (`Microsoft-Event` instead of `Microsoft-WindowsEvent`) silently drops the entire pipeline [@ms-learn-ama-windows-events]. This article walks the full path with a concrete worked example, names where the convergence actually stops, and gives a six-step recipe to build the pipeline yourself.

1. One event, three portals, nine minutes

At 14:03:17 UTC on a Tuesday, winword.exe on the host MAL-CONTOSO-PRD-04 spawns a child process: powershell.exe -EncodedCommand JABwAD0AJwBoAHQAdABwADoALwAv.... Sysmon, which loads early in the boot sequence as a boot-start kernel driver, writes a single ProcessCreate record (Event ID 1) to the Windows event log channel Microsoft-Windows-Sysmon/Operational [@ms-learn-sysmon]. The record is roughly two kilobytes of XML with a stable ProcessGuid field that uniquely identifies the new process across the host's lifetime [@ms-learn-defrag-tools-sysmon].

At 14:03:21 UTC, the same record appears in the Event table of an Azure Log Analytics workspace named law-contoso-secops [@ms-learn-event-table]. At 14:05:00 UTC, a Microsoft Sentinel scheduled analytics rule fires its five-minute KQL query, matches a parent-image heuristic (winword.exe -> powershell.exe -EncodedCommand), and produces a SecurityAlert row whose Entities JSON column names the host, the parent process, the child process, and the encoded command line [@ms-learn-sentinel-scheduled-rules] [@ms-learn-sentinel-entities]. At 14:07:42 UTC, a Microsoft Defender for Cloud (MDC) alert -- emitted by the MDC for Servers cloud workload protection plan, which sits on top of the Microsoft Defender for Endpoint (MDE) sensor on that same host -- shows up in the workspace's SecurityAlert table with the title Suspicious PowerShell command line [@ms-learn-mdc-defender-servers] [@ms-learn-mdc-mde-integration]. And at 14:09:30 UTC -- nine minutes and thirteen seconds after the kernel call -- a single incident appears in the Microsoft Defender XDR portal at security.microsoft.com. Its title: Multi-stage incident on one endpoint. Its alert tab lists three rows: one from Sentinel, one from MDC, and (because MDE was also installed) one from Defender for Endpoint's native detection engine [@ms-learn-defender-xdr-incidents] [@ms-learn-xdr-correlation].

Three independent detection systems, three different timestamps, three different alert grammars, one incident. How?

That question is the spine of this article. It is not a marketing question -- "look how unified it is" -- because the convergence is partial and the seams are load-bearing. It is an engineering question: which hops happen where, what does each hop cost in latency and money, and where does the unification actually stop?

Key idea: Microsoft Defender XDR is not a single product. It is a correlation surface that fans in three structurally different pipelines: Sentinel's KQL analytics rules over Log Analytics, Defender for Cloud's cloud-workload-protection (CWPP) alerts from MDC plans (servers, containers, SQL, storage, App Service), and the native Defender stack (Endpoint, Identity, Office, Cloud Apps). The fan-in is real but partial: Sentinel cross-workspace correlation, MDC posture findings, and most third-party connectors stay outside the unified incident graph [@ms-learn-defender-xdr-overview] [@ms-learn-mdc-xdr-concept].

Here is the full path the Sysmon record takes from kernel to portal. Each numbered box is a real component with its own owner team, deployment lifecycle, and failure mode:

flowchart LR A["1 Sysmon kernel ETW provider on host"] B["2 Azure Monitor Agent + Data Collection Rule"] C["3 Log Analytics workspace Event/SecurityEvent tables"] D["4 Sentinel scheduled or NRT analytics rule -- KQL"] E["5 MDC alert via Defender for Servers + MDE sensor"] F["6 Defender XDR correlation engine -- security.microsoft.com"] A --> B --> C --> D --> F C --> E --> F classDef src fill:#e8f4ff,stroke:#2b6cb0,color:#1a365d classDef sink fill:#fffaf0,stroke:#dd6b20,color:#7b341e class A,B,C src class F sink

The diagram understates how separate these hops are. Box 2 lives on the host. Box 3 is a multi-tenant Azure Data Explorer cluster [@ms-learn-adx-docs]. Box 4 runs on Sentinel's serverless query engine inside the workspace's home region. Box 5 is a Defender for Cloud plan with its own SKU, scoped to an Azure subscription. Box 6 is a separate web portal in a separate Microsoft 365 tenant scope. Each one rolled out at a different time, was renamed at least once, and absorbed a different earlier product. The next section recovers the lineage that explains why.

2. Three lineages that became one portal

The three pipelines that converge at hop 6 did not start as siblings. They started as three separate Microsoft product lines aimed at three different buyer personas: an Azure subscription owner who wanted posture scoring, a Windows engineer who wanted endpoint detection, and a SOC analyst who wanted a SIEM. Reading the path right-to-left -- from the unified portal back to its three roots -- is the only honest way to understand why the seams look the way they do.

A platform that ingests security-relevant logs from many sources, normalizes them into a queryable schema, runs correlation rules to produce alerts, and groups related alerts into incidents that a SOC analyst triages. Microsoft Sentinel is a SIEM [@ms-learn-sentinel-overview]. A platform (often packaged with a SIEM) that runs playbooks in response to alerts -- isolating a host, disabling an account, opening a ticket. In Microsoft's stack, SOAR is implemented as Azure Logic Apps invoked from Sentinel automation rules [@ms-learn-sentinel-soar]. A sensor that runs on a single endpoint, collects rich process / file / network / registry telemetry, applies behavioural detections locally and in the cloud, and exposes response actions (terminate process, isolate machine, collect investigation package). Microsoft Defender for Endpoint is an EDR [@ms-learn-mde-landing] [@ms-learn-mde-eda]. A correlation layer that fans in alerts and entities from multiple Microsoft-or-vendor detection products (endpoint, identity, email, cloud apps, cloud workloads) and merges related alerts into a single incident graph. Microsoft Defender XDR is Microsoft's XDR; the term was popularized by Palo Alto Networks in 2018 [@ms-learn-defender-xdr-overview] [@pan-blog-xdr-journey].

The CSPM line started first. In December 2015, Microsoft put Azure Security Center (ASC) into public preview as a per-subscription posture dashboard that scored Azure resources against a baseline of hardening recommendations [@azure-blog-asc-preview-2015]. ASC went generally available in July 2016 alongside JIT VM access [@ms-security-blog-asc-ga-2016]. Public sources frequently report ASC GA as "October 2015" or "October 2016." The primary Azure blog from December 2015 explicitly says "Azure Security Center -- now in public preview," and the July 2016 Microsoft Security blog announces the GA wave of new capabilities. The December 2015 preview / mid-2016 GA framing matches both authoritative announcements [@azure-blog-asc-preview-2015] [@ms-security-blog-asc-ga-2016]. Over the next five years ASC absorbed runtime protection plans -- Defender for Servers, SQL, Storage, App Service, Containers -- and was renamed Microsoft Defender for Cloud at Ignite Fall 2021, the same wave that renamed Microsoft Cloud App Security to Microsoft Defender for Cloud Apps (MDCA) [@ms-learn-mdc-introduction] [@ms-learn-mdca-rename-2021].

The SIEM line is much younger. Microsoft announced Azure Sentinel in public preview on February 28, 2019 as the first cloud-native SIEM from a hyperscaler, built on top of Azure Log Analytics and the Kusto Query Language [@ms-blog-sentinel-preview-2019]. It went GA on September 24, 2019 [@ms-security-blog-sentinel-ga-2019]. It was renamed Microsoft Sentinel in November 2021 (same Ignite wave). Sentinel inherited every Log Analytics integration that Azure Monitor already had, which meant it could ingest Windows event logs, syslog, Office 365 audit, Microsoft Entra ID sign-ins, and anything you could shove into a workspace with a custom collector [@ms-learn-sentinel-data-connectors-ref].

The XDR line landed last. In September 2020 Microsoft announced "Microsoft unified SIEM and XDR" as a direction, and rolled the Office 365 ATP and Microsoft Defender ATP detection surfaces into a single portal called Microsoft 365 Defender [@ms-security-blog-unified-siem-xdr-2020]. The portal was renamed Microsoft Defender XDR in early 2024, and the SIEM and XDR portals were merged at Ignite November 2023, with the unified Microsoft security operations platform going generally available in July 2024 [@ms-blog-ignite-2023] [@ms-security-blog-unified-secops-2024]. The Sentinel experience inside the Azure portal will be retired on March 31, 2027 (a deadline extended from its original July 1, 2026 target); after that date, Sentinel lives only inside security.microsoft.com [@ms-learn-sentinel-azure-portal-retiring] [@helpnetsec-sentinel-defender-timeline].

gantt title Three lineages converging at security.microsoft.com dateFormat YYYY-MM axisFormat %Y

section EDR line
Sysmon v1 (Sysinternals)         :done, 2014-08, 12M
Microsoft Defender ATP (EDR)     :done, 2016-03, 60M
Renamed Microsoft Defender for Endpoint :done, 2020-09, 24M

section CSPM and CWPP line
Azure Security Center preview    :done, 2015-12, 8M
Azure Security Center GA         :done, 2016-07, 64M
Renamed Microsoft Defender for Cloud :done, 2021-11, 36M

section SIEM line
Azure Sentinel preview           :done, 2019-02, 7M
Azure Sentinel GA                :done, 2019-09, 26M
Renamed Microsoft Sentinel       :done, 2021-11, 24M

section XDR convergence
Microsoft 365 Defender portal    :done, 2020-09, 38M
Sentinel merged into Defender portal :done, 2023-11, 8M
Unified secops GA                :done, 2024-07, 24M
Sentinel Azure portal retires    :crit, 2027-03, 1M

Three things matter about this timeline for the rest of the article. First, the CSPM/CWPP line is older than either SIEM or XDR -- which is why the Defender for Cloud team owns its own alert format, its own subscription-scoped permissions model, and its own portal at portal.azure.com/#blade/Microsoft_Azure_Security, none of which fully merge into the unified Defender experience even today. Second, Sentinel inherited Log Analytics, not the other way around -- so the storage substrate, the agent (Azure Monitor Agent), and the query language (KQL) all predate Sentinel by years and serve far more workloads than security. Third, the unified portal is the new arrival, not the foundation. The convergence is grafted on top of three pre-existing pipelines, and that grafting -- not the products themselves -- is what makes the architecture interesting.

3. The pre-cloud SIEM bottleneck

To understand why Sentinel was built the way it was, hold the question in mind that every SIEM buyer asked their finance team between roughly 2008 and 2018: "Why does each new server cost me a license-tier upgrade?"

Classic on-premises SIEMs -- Splunk Enterprise, ArcSight, QRadar -- priced by ingested gigabytes per day, billed as a perpetual or annual license tied to a tier. Crossing a tier boundary triggered a forklift purchase. Storage was on-prem disk, and retention was constrained by how much steel you bought; compute was on the same hardware, so peak query load contended with peak ingest. The cost shape was step-wise, and the constraint that bound it most painfully was peak ingest rate.

Cost dimension	Classic on-prem SIEM	Cloud-native SIEM (Sentinel)
Ingest billing unit	License tier (GB/day, stepped)	Per-GB ingest (continuous) [@ms-learn-sentinel-billing]
Storage billing unit	Bundled with license tier	Per-GB-month retention (continuous) [@ms-learn-sentinel-billing]
Compute billing unit	Bundled / hardware capex	Per-query bytes scanned (serverless) [@ms-learn-adx-docs]
Capacity planning	Estimate peak GB/day a year out	None -- pay for what you ingested last hour
New data source onboarding	Re-tier and order disks	Add a Data Collection Rule [@ms-learn-dcr-overview]

The reframe Sentinel proposed -- and that the Kusto/Log Analytics substrate enabled -- was to separate the three cost axes: ingest, storage retention, and query compute. Each axis bills continuously and independently. There is no tier to cross. Adding a new data source is a Data Collection Rule edit, not a procurement event. Retaining last quarter's logs another year is a per-GB-month flag, not a disk purchase [@ms-learn-sentinel-billing].

Note: Aha #1 -- the economic reframe. What looked like a pricing change ("SaaS billing") was actually an architectural change. Classic SIEMs bundled ingest, storage, and compute because the hardware bundled them. Once each axis lives on a different cloud service (Event Hubs / DCR for ingest, ADX for storage, KQL serverless query for compute), there is no bundle to defend. The SaaS bill is downstream of the deconstructed architecture, not the cause of it.

This deconstruction is what makes the Sentinel pipeline interesting upstream of the SOC. When ingest is a separately-billed continuous variable, the Data Collection Rule becomes the most important security artifact in the deployment: it determines what flows in and therefore both what costs you incur and what you can possibly detect. (The accuracy-report follow-up that drives section 10 hinges on exactly one wrong word in a DCR.) When query compute is serverless and per-byte, a long-running threat hunt over a year of process-creation events is a question of dollars, not of capacity-plan slack. And when storage retention is a per-GB-month flag, the question "should we retain this for compliance?" decouples from "do we have rack space?"

Sentinel offers a flexible and predictable pricing model. Pay-as-you-go pricing lets you pay for what you use, while commitment tiers provide guaranteed discounts. [@ms-learn-sentinel-billing]

That is the pricing-page sales line. The architectural truth underneath it is that the three pre-cloud bundles unbundled, and once they unbundled, the SIEM was free to grow horizontally with the rest of the cloud workload. That is exactly what happened with Sentinel between 2019 and 2024: it accumulated 300+ data connectors for every Azure service, every Microsoft 365 surface, every major SaaS log feed, and a long tail of third-party security tools [@ms-learn-sentinel-data-connectors-ref]. None of that catalog would have been economically sane on a per-GB/day license tier.

But the unbundle was not free. The price of separately-billed continuous axes is that you have to measure on all three axes. You now need to know your steady-state ingest rate, your retention policy, and your hunt query patterns. The next section steps inside the substrate that makes those measurements -- and the queries on top of them -- possible.

4. The cloud-native SIEM substrate: KQL on Log Analytics

Microsoft Sentinel is a thin layer over a much older substrate. That substrate is Azure Monitor Log Analytics, which itself is a security-and-multitenancy wrapper around Azure Data Explorer (ADX), the cluster engine that runs Kusto Query Language (KQL) [@ms-learn-adx-docs]. Understanding the stack matters because almost everything Sentinel can or cannot do is determined by what Log Analytics and KQL can or cannot do, not by anything Sentinel itself implements.

A multi-tenant namespace inside Azure Monitor that stores ingested telemetry in typed tables and exposes them for KQL query. Each workspace lives in a specific Azure region and Azure subscription, has its own access controls, and bills ingest and retention independently. Sentinel "is enabled" on a workspace; the workspace is the storage and query unit [@ms-learn-sentinel-overview]. A read-only, pipe-composed query language for time-series and tabular log data, originally developed for Azure Data Explorer. KQL is the lingua franca of Azure Monitor Logs, Microsoft Sentinel analytics, Microsoft Defender XDR advanced hunting, and several other Microsoft data services [@ms-learn-adx-docs] [@ms-learn-advanced-hunting].

The layering is shown below. Notice that KQL itself spans four Microsoft surfaces, of which Sentinel is just one. KQL's polymorphism -- one query language across Monitor, Sentinel, Defender XDR advanced hunting, and ADX itself -- is the single most under-appreciated decision in the Microsoft security stack. It is also the reason your KQL skills move across teams.

flowchart TB subgraph L1["Layer 1 -- storage cluster"] ADX["Azure Data Explorer (Kusto engine)"] end subgraph L2["Layer 2 -- managed namespace"] LA["Log Analytics workspace -- typed tables, RBAC, regional"] end subgraph L3["Layer 3 -- query surfaces"] AZM["Azure Monitor logs -- ops + perf"] SEN["Microsoft Sentinel -- SIEM analytics rules"] XDR["Defender XDR -- advanced hunting"] ADXQ["ADX direct -- analytics + BI"] end ADX --> LA LA --> AZM LA --> SEN LA --> XDR ADX --> ADXQ classDef stor fill:#e8f4ff,stroke:#2b6cb0,color:#1a365d classDef ns fill:#fff5d6,stroke:#b7791f,color:#5f370e classDef ui fill:#e6fffa,stroke:#319795,color:#234e52 class ADX stor class LA ns class AZM,SEN,XDR,ADXQ ui

The substrate predates Sentinel by years. Log Analytics was the rebranded form of Operations Management Suite (OMS), which Microsoft introduced in 2015 as a cloud companion to System Center Operations Manager. The agent that fed OMS -- the Microsoft Monitoring Agent (MMA), sometimes also called the Log Analytics agent -- shared its agent lineage with the System Center Operations Manager agent and ran on Windows and Linux servers to ship event logs and performance counters to the workspace [@ms-learn-laa-deprecated] [@lunavi-oms-azure-monitor]. ADX (Kusto) was productised externally in 2018 after years of internal Microsoft use as the engine behind Bing telemetry, Office 365 ops, and Azure monitoring [@ms-learn-adx-docs].

The naming continuity is worth pausing on. *Log Analytics* (2016) replaced *OMS* (2015), which replaced *Application Insights workspaces* (2014), which absorbed parts of *Operations Manager* (2007). The data store underneath was *Kusto* the whole time. By the time Azure Sentinel launched in 2019 [@ms-blog-sentinel-preview-2019], the substrate had been hardened for four years at hyperscale, mostly for non-security workloads. Sentinel did not have to invent the storage; it inherited it. This is also why the same KQL skill maps onto application telemetry and infrastructure metrics, not just security.

Two consequences of the substrate inheritance shape every hop downstream:

Schema is per-table, not per-product. A Log Analytics workspace exposes typed tables like Event (Windows event log records), SecurityEvent (Windows Security channel), Syslog, Heartbeat, SecurityAlert, DeviceProcessEvents (mirrored from Defender XDR's advanced hunting schema), Perf, and any number of Custom_CL tables [@ms-learn-event-table] [@ms-learn-securityevent-table]. KQL queries are written against tables, not against products. A Sentinel analytics rule is just a saved KQL query that runs on a schedule and emits a row into SecurityAlert.
Cross-workspace and cross-table joins are first-class. Because the substrate is a real query engine, you can join between SecurityEvent and SigninLogs and DeviceProcessEvents in a single rule. You can use workspace("law-other").Event to reach into a separate workspace. You can call externaldata() to read from a blob. This expressive power is the source of both Sentinel's flexibility and its operational complexity: the rule that worked in test stops working in prod because the test workspace did not have a SigninLogs table or because the cross-workspace permission is missing [@ms-learn-sentinel-threat-detection].

For the Sysmon worked example: the kernel record will land in the Event table (because Sysmon's channel is treated as a generic Windows event log, not as the SecurityEvent Security channel). The detection KQL will live as a Sentinel scheduled analytics rule that reads from Event, filters to Source == "Microsoft-Windows-Sysmon" and EventID == 1, parses the XML payload (the next section will show the exact pattern), and emits a SecurityAlert row. That SecurityAlert row is what hop 6 ultimately fans in. The substrate did all the heavy lifting; Sentinel just wrote the rule.

5. The XDR reframe: from per-product portals to a single incident graph

If the SIEM substrate is "many tables, one query engine," the XDR reframe is "many alert sources, one incident graph." Microsoft Defender XDR exists because by 2019 a typical Microsoft enterprise customer had four or five separate Microsoft security portals -- one for Office 365 ATP, one for Microsoft Defender ATP, one for Microsoft Cloud App Security, one for Azure AD Identity Protection, and the Azure Security Center / Sentinel pair. Each portal had its own alert grammar, its own console, and its own analyst workflow. The XDR reframe is to keep the alert sources but merge the analyst surface.

A correlation surface at `security.microsoft.com` that fans in alerts and entity data from the Microsoft Defender product family (Endpoint, Identity, Office 365, Cloud Apps), Microsoft Sentinel, and Microsoft Defender for Cloud's runtime CWPP plans, then merges related alerts into incidents using shared entity identifiers (user, device, file hash, IP, URL) [@ms-learn-defender-xdr-overview] [@ms-learn-defender-xdr-incidents].

The mechanism the merge uses is the entity graph. When any of the source pipelines emits an alert, it is required to attach a set of typed entities (e.g., Host = MAL-CONTOSO-PRD-04, Process = winword.exe, Account = CONTOSO\\jdoe) to that alert [@ms-learn-sentinel-entities]. The Defender XDR correlation engine reads incoming alerts, normalizes the entity values, and groups alerts whose entities overlap in time and identity into a single incident [@ms-learn-xdr-correlation]. That is the entire trick. It is conceptually simple. Operationally it has many edge cases, which section 8 returns to.

For the worked example, the three alert sources (Sentinel KQL rule, MDC for Servers, MDE) each emit a separate alert. Each alert lists Host = MAL-CONTOSO-PRD-04 and (for two of the three) ProcessGuid = {abc-...}. The correlation engine merges them on the host entity within a sliding time window. Result: one incident with three correlated alerts, not three separate incidents. The temporal fan-out is shown below; the fan-in geometry returns in section 6.6.

sequenceDiagram autonumber participant K as Host kernel (Sysmon) participant LA as Log Analytics workspace participant SEN as Sentinel scheduled rule participant MDC as MDC for Servers alert participant MDE as MDE native detection participant XDR as Defender XDR correlation K->>LA: 14:03:21 -- Event row (ProcessGuid abc) LA->>SEN: 14:05:00 -- 5-min query fires SEN->>XDR: 14:05:04 -- SecurityAlert from KQL K->>MDE: 14:03:17 -- local EDR sensor signal MDE->>MDC: 14:06:30 -- MDE telemetry surfaces MDC alert MDC->>XDR: 14:07:42 -- SecurityAlert from MDC plan MDE->>XDR: 14:08:11 -- DeviceAlertEvents direct XDR->>XDR: 14:09:30 -- merge on host + ProcessGuid -> Incident I-7842

Two things in the diagram deserve to be noticed. First, the three alerts arrive in a window that is small but not synchronous: about six minutes from earliest to latest, all gated by the slowest pipeline (Sentinel's five-minute scheduled query). Second, MDE shows up twice: once as the source that feeds MDC's CWPP plan (hop 5 in the master diagram), and once as a native Defender XDR alert source. The two are the same sensor data routed through two different alert grammars to the same correlation surface. The fact that the correlation engine deduplicates them on ProcessGuid is not accidental -- it is the load-bearing identifier that makes the unification work for endpoint events. For non-endpoint sources (cloud-control-plane alerts from MDC for Storage, for example), there is no equivalent shared identifier, and the deduplication has to fall back on weaker entity matches like account name or IP. That is where the convergence frays.

The next section walks the six hops in order, naming the artifact at each hop and the failure mode that lives there. Hops 1 through 4 are the SIEM lineage. Hop 5 is the CWPP lineage. Hop 6 is the XDR fan-in.

6. Walking the six hops

6.1 Hop 1 -- The kernel emission

The Sysmon driver -- SysmonDrv.sys -- is registered as a Windows boot-start driver under HKLM\SYSTEM\CurrentControlSet\Services\SysmonDrv with Start=0, which means the I/O manager loads it during the early-boot phase before the bulk of user-mode services start; it also registers as an event-tracing-for-Windows (ETW) provider. On every process creation, it hooks the kernel's PsSetCreateProcessNotifyRoutineEx callback, builds an event record, and writes it to the Windows event log channel Microsoft-Windows-Sysmon/Operational [@ms-learn-sysmon] [@ms-learn-defrag-tools-sysmon]. The record carries roughly thirty fields, including the parent and child image paths, the command lines, the user SID, the integrity level, the hashes (configurable: MD5, SHA1, SHA256, IMPHASH), the parent and child ProcessGuid values, and the kernel-side timestamp.

A common slip: Sysmon's driver is not an Early Launch Anti-Malware (ELAM) driver. ELAM is a separate, stricter Windows category for anti-malware vendors whose drivers must be certified by Microsoft and registered under HKLM\SYSTEM\CurrentControlSet\Control\EarlyLaunch. Sysmon ships as an ordinary boot-start driver (Start=0 under its Services\SysmonDrv key); it loads early enough to observe most user-mode activity from the start, but it does not occupy the ELAM slot. A reader who internalizes the wrong classification will go looking for a SysmonDrv entry under EarlyLaunch and not find one [@ms-learn-sysmon].

A 128-bit identifier Sysmon assigns to every new process. Unlike the OS-assigned PID, which the kernel can recycle as processes exit, ProcessGuid is unique across the host's lifetime and lets downstream tooling reassemble a process tree even after PIDs have been reused. The Microsoft Sysmon page documents the property -- "a unique value for this process across a domain to make event correlation easier" -- but does not document how the GUID is constructed; downstream KQL queries and Defender XDR's advanced hunting schema rely only on its uniqueness, not on its internal composition [@ms-learn-sysmon].

There is a subtle field nuance worth knowing. Sysmon also emits LogonGuid, LogonId, and User on a ProcessCreate event. These three are post-impersonation values -- they reflect the security context the new process was created under, which can differ from the token of the parent. For service-impersonation chains (a service spawning a child under a different account), ignoring this distinction will mislead an analyst on who "owned" the process. KQL detection queries should project both parent and child user/SID and reconcile them explicitly.

For the worked example, the kernel emission at 14:03:17 UTC contains, among other fields:

EventID:       1
TimeCreated:   2026-06-02T14:03:17.412Z
Computer:      MAL-CONTOSO-PRD-04
ProcessGuid:   {62b9c5cf-7c64-67ab-2e00-000000003200}
ProcessId:     8124
Image:         C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
CommandLine:   powershell.exe -EncodedCommand JABwAD0AJwBoAHQAdABwADoALwAv...
ParentProcessGuid:   {62b9c5cf-7b21-67ab-2c00-000000003200}
ParentProcessId:     6210
ParentImage:   C:\Program Files\Microsoft Office\root\Office16\winword.exe
ParentCommandLine:   "winword.exe" /n "C:\Users\jdoe\Downloads\invoice.docm"
User:          CONTOSO\jdoe
IntegrityLevel: Medium
Hashes:        SHA256=04ED...

Nothing further happens at hop 1 until someone reads the channel. The kernel will not push the event off the host; it will only sit in the local event log, rotating by size or age, until an agent picks it up. That is hop 2.

6.2 Hop 2 -- Azure Monitor Agent shipping via a Data Collection Rule

The agent that reads the Sysmon channel and ships it to the workspace is the Azure Monitor Agent (AMA). AMA replaced the older Microsoft Monitoring Agent (MMA) / Log Analytics agent, which Microsoft retired effective August 31, 2024 [@ms-learn-laa-deprecated]. Customers still running MMA past that date are in unsupported territory, and -- this is the critical operational fact -- AMA does not automatically pick up where MMA left off. AMA requires explicit migration: a Data Collection Rule (DCR) describing which events to collect and which workspace to send them to [@ms-learn-ama-migration].

A modern Microsoft agent that runs on Windows and Linux servers (Azure VM, Arc-enabled, or on-prem) and ships event logs, performance counters, syslog, and custom text files to one or more Log Analytics workspaces, driven entirely by Data Collection Rule (DCR) configurations [@ms-learn-ama-overview]. An ARM-managed configuration object that names a data source type (e.g., `windowsEventLogs`), an XPath-based subscription (which channels and which event IDs), and one or more destinations (typically a `logAnalyticsWorkspace` + `streams` mapping such as `Microsoft-Event` for the generic `Event` table or `Microsoft-WindowsEvent` for the more recent typed Windows event ingestion path). DCRs are assigned to one or more agents via a Data Collection Rule Association (DCRA) [@ms-learn-dcr-overview] [@ms-learn-ama-windows-events]. flowchart LR CH["Windows event channels (XPath subscription)"] AMA["Azure Monitor Agent process"] DCR["Data Collection Rule (cached locally)"] ING["Log Analytics ingestion endpoint -- regional HTTPS"] TBL["Workspace table -- Event / SecurityEvent / WindowsEvent"] CH --> AMA DCR --> AMA AMA --> ING ING --> TBL classDef cfg fill:#fff5d6,stroke:#b7791f,color:#5f370e classDef agent fill:#e8f4ff,stroke:#2b6cb0,color:#1a365d classDef sink fill:#e6fffa,stroke:#319795,color:#234e52 class DCR cfg class AMA,CH agent class ING,TBL sink

Note: The MMA-to-AMA silent-miss trap. A workspace that is still in transition between MMA and AMA can have agents on the same host both running, both shipping the same Event row, and producing double counts. Worse, a host that has had MMA uninstalled but a DCR mis-assigned will stop shipping entirely -- and because Sysmon writes to the local event log no matter what, no alert fires on the host itself. The first signal of the gap is silence in the Event table for that Computer value, which a Sentinel "stale data source" watchdog rule must explicitly detect. Microsoft retired MMA effective August 31, 2024 [@ms-learn-laa-deprecated].

For the Sysmon channel specifically, AMA needs a DCR whose windowsEventLogs block names the XPath subscription Microsoft-Windows-Sysmon/Operational!*[System[(EventID=1)]] (or a broader filter that includes EventIDs 1, 3, 7, 8, 10, 11). The stream name in the destination block determines which table the record lands in: a DCR that names Microsoft-Event ships into the generic Event table; one that names Microsoft-WindowsEvent ships into the newer WindowsEvent table; and naming anything else silently emits nothing [@ms-learn-ama-windows-events] [@ms-learn-sentinel-data-connectors-ref]. The AMA does not log a hard error in this case; the events simply never appear, and the analyst sees a dashboard that is missing the wave.

Hop 2 finishes at about 14:03:19 UTC for the worked example -- two seconds after the kernel emission. The record is now in the workspace's ingest buffer.

6.3 Hop 3 -- Workspace ingestion and the table-choice question

The ingestion endpoint validates the record against the named stream's schema, applies any DCR-side transformations, and persists the row into the destination table. From here on the record is queryable via KQL with end-to-end ingestion latency typically in the low minutes [@ms-learn-event-table]. For the Sysmon channel the destination table is almost always Event, because the SecurityEvent table is the Windows Security channel only (the AMA securityEvents data source), and the Sysmon channel is a separate operational channel [@ms-learn-securityevent-table].

The table choice matters because it changes the shape of the row and the cost of querying it. The two relevant tables for Windows event data behave as follows:

Property	`Event` (Microsoft-Event stream)	`WindowsEvent` (Microsoft-WindowsEvent stream)
Source	AMA `windowsEventLogs` data source [@ms-learn-ama-windows-events]	AMA `windowsEventLogs` data source (newer typed path) [@ms-learn-ama-windows-events]
EventData shape	XML in `EventData` column (string)	Pre-parsed JSON in `EventData` (dynamic)
Cost characteristic	Standard ingest pricing [@ms-learn-sentinel-billing]	Standard ingest pricing
Best for	Mixed sources, simple filters	Channels with deep parsing needs
KQL parse pattern	`parse_xml(EventData)` per row	Direct property access

In production, most Sysmon-on-Windows pipelines run on the older Event table with a parse_xml(EventData) shim. The parse is not cheap -- it allocates per row -- but it is the most common pattern because the older table predates the typed WindowsEvent path and customer queries already exist against it. New deployments should consider the newer table if their detection logic touches many fields per row [@ms-learn-ama-windows-events].

A representative KQL detection that runs against the older Event table for the worked example looks like the snippet below. Show it to a SOC analyst and they will read it left-to-right; show it to a Kusto engineer and they will tell you the parse_xml is the expensive part.

The KQL that parses a Sysmon event out of the older Event table follows a four-step idiom that is worth walking explicitly, because the same shape appears in every detection a SOC writes against XML-shaped Windows event data. Step one: parse_xml(EventData) reads the entire EventData payload (a string column) and returns a dynamic JSON tree whose root is DataItem.EventData and whose interesting children are an array of <Data Name="...">value</Data> elements [@ms-learn-kusto-parse-xml]. Step two: mv-expand ev = ...DataItem.EventData.Data flattens that array so each <Data> child becomes its own row -- a long-form representation where one event becomes thirty rows, one per field. Step three: extend Field = tostring(ev["@Name"]), Value = tostring(ev["#text"]) projects the XML attribute and text payload into two typed columns named Field and Value. Step four: evaluate pivot(Field, take_any(Value), TimeGenerated, Computer) invokes the Kusto pivot plugin, which rotates the long-form (Field, Value) rows back into a wide row with one column per field name -- so after the pivot, CommandLine, Image, ParentImage, and ProcessGuid become first-class columns the detection can filter on as if they had been typed all along [@ms-learn-kusto-pivot-plugin]. The same chain adapts to any other EventID (3 / NetworkConnect, 11 / FileCreate, etc.) and, with one less hop, to the typed WindowsEvent table where EventData is already pre-parsed JSON.

Quick reference, in margin form: parse_xml(EventData) -> dynamic JSON tree; mv-expand ev = ...EventData.Data -> one row per <Data> element; extend Field/Value -> typed Field/Value columns; evaluate pivot(Field, take_any(Value), ...) -> wide row, one column per field. The pivot step is what turns "thirty long-form rows" into "one wide row with named columns"; without it the detection has to filter on the Field/Value pairs directly, which is much harder to write and to read [@ms-learn-kusto-pivot-plugin].

```kql Event | where TimeGenerated > ago(5m) | where Source == "Microsoft-Windows-Sysmon" and EventID == 1 | extend ev = parse_xml(EventData).DataItem.EventData.Data | mv-expand ev | extend Field = tostring(ev["@Name"]), Value = tostring(ev["#text"]) | evaluate pivot(Field, take_any(Value), TimeGenerated, Computer) | where ParentImage endswith "winword.exe" and Image endswith "powershell.exe" and CommandLine contains "-EncodedCommand" | project TimeGenerated, Computer, User, ParentImage, ParentProcessGuid, Image, ProcessGuid, CommandLine, Hashes | extend HostCustomEntity = Computer, AccountCustomEntity = User, ProcessCustomEntity = ProcessGuid ```

The five lines after the pivot are the actual detection: an Office process spawning PowerShell with -EncodedCommand. The three *CustomEntity columns at the bottom are what wire this alert into the Defender XDR correlation engine at hop 6 -- they become typed entities on the resulting SecurityAlert row [@ms-learn-sentinel-entities].

Note: Why the row of CustomEntity columns matters. A Sentinel analytics rule that produces a SecurityAlert without entity mappings will still alert -- and will still be readable by an analyst -- but it will not participate in cross-pipeline correlation at hop 6. The XDR fan-in matches on entity values, and an alert with no entities has nothing to match on. This is a common oversight when migrating older queries into Sentinel from on-prem SIEMs that did not have an equivalent concept.

Hop 3 finishes at about 14:03:21 UTC: four seconds after kernel emission, with the row written to the workspace's Event table and indexed for KQL query.

6.4 Hop 4 -- Sentinel analytics rule emits a SecurityAlert

Microsoft Sentinel supports several detection-rule shapes. The five that matter for understanding the Sysmon pipeline are summarized below, with the timing characteristics that drive end-to-end latency for hop 4.

A KQL query that Sentinel runs on a fixed schedule (default 5 minutes, minimum 5 minutes). When the query returns rows, each row -- subject to grouping configuration -- becomes a `SecurityAlert` row in the workspace and an alert object in Sentinel and in Defender XDR [@ms-learn-sentinel-scheduled-rules]. The Sentinel-rule configuration that names which output columns of the KQL detection map to which typed entities (Account, Host, Process, IP, URL, FileHash, etc.). Without entity mappings, an alert is "orphan" with respect to the Defender XDR correlation engine [@ms-learn-sentinel-entities].

The five rule shapes and where they fire in the Sysmon path:

Rule type	Query cadence	Typical end-to-end latency	Sysmon use
Scheduled analytics [@ms-learn-sentinel-scheduled-rules]	Every 5+ min	5-8 min from ingest	The default for ProcessCreate detections
Near-real-time (NRT) [@ms-learn-sentinel-nrt-rules]	Every 1 min	1-2 min from ingest	High-priority single-event matches
Microsoft security (parent-product)	Tied to source product	Sub-minute	Pass-through for MDE / MDC / MDCA alerts
Fusion (multistage) [@ms-learn-sentinel-fusion]	ML-driven, continuous	Hours	Cross-source attack-pattern detection
Threat-intelligence map [@ms-learn-sentinel-threat-detection]	Continuous	Sub-minute	IOC matching on `Event`-derived hashes

For the worked example, the detection runs as a scheduled analytics rule at five-minute cadence. The rule fires at 14:05:00 UTC, the query returns one row matching winword.exe -> powershell.exe -EncodedCommand, and a SecurityAlert is emitted at 14:05:04 UTC. The alert carries the HostCustomEntity, AccountCustomEntity, and ProcessCustomEntity mappings that the rule defined.

{`// Three alerts arriving from three pipelines, each with entities. const sentinelAlert = { source: 'Sentinel', time: '14:05:04Z', entities: { Host: 'MAL-CONTOSO-PRD-04', Process: '{62b9c5cf-7c64-67ab-2e00-000000003200}' } }; const mdcAlert = { source: 'MDC for Servers (via MDE)', time: '14:07:42Z', entities: { Host: 'MAL-CONTOSO-PRD-04', File: 'powershell.exe' } }; const mdeAlert = { source: 'MDE native', time: '14:08:11Z', entities: { Host: 'MAL-CONTOSO-PRD-04', Process: '{62b9c5cf-7c64-67ab-2e00-000000003200}' } }; function correlate(alerts, windowMin = 30) { const byHost = new Map(); for (const a of alerts) { const k = a.entities.Host; if (!byHost.has(k)) byHost.set(k, []); byHost.get(k).push(a); } return [...byHost.entries()].map(([host, alts]) => ({ incidentKey: 'host:' + host, alerts: alts.map(a => a.source) })); } console.log(correlate([sentinelAlert, mdcAlert, mdeAlert])); // -> [{ incidentKey: 'host:MAL-CONTOSO-PRD-04', // alerts: ['Sentinel','MDC for Servers (via MDE)','MDE native'] }] `}

The toy correlator above only keys on Host. The real one also keys on Process (ProcessGuid where present), Account, IP, URL, and FileHash, and uses a sliding window plus a confidence-weighted merge that allows weak entities (file name) to participate when strong entities (ProcessGuid) overlap [@ms-learn-xdr-correlation]. The result is the same: three alerts in, one incident out.

Two other Sentinel detection paths deserve a mention even though they did not fire for this specific worked example. UEBA anomalies -- when enabled, Sentinel writes per-user and per-host baselines into BehaviorAnalytics and IdentityInfo tables; analytics rules can join these to flag a normally-quiet jdoe spawning encoded PowerShell as anomalous independent of any specific signature [@ms-learn-sentinel-threat-detection]. Fusion is an ML-driven multistage detector that operates over the broader alert + event corpus and emits Fusion-named incidents when it sees a chain that resembles an attack pattern (e.g., a phishing alert followed by a credential-access alert followed by a process-spawn anomaly within an hour on the same identity) [@ms-learn-sentinel-fusion]. Fusion's strength is correlation across products you would not have thought to correlate manually; its weakness is opacity, which §9 returns to.

There is one further detection family worth introducing here because §10's recipe will explicitly avoid it: Defender XDR Custom Detections. These are KQL queries authored not in Sentinel but in the unified portal's advanced hunting surface, and they emit alerts directly into Defender XDR rather than via the SIEM analytics-rule pipeline [@ms-learn-sentinel-custom-detections]. Custom detections can read DeviceProcessEvents and the rest of the Defender advanced hunting schema, which is fed by the MDE sensor independent of Sysmon. For the worked example, a Custom Detection equivalent to the Sentinel scheduled rule would also have fired -- but it would have fired against MDE's DeviceProcessEvents table, not against Log Analytics Event. The two paths are not interchangeable. Microsoft's documentation is explicit that custom detections operate over the Defender XDR-internal advanced hunting schema, not over arbitrary Log Analytics tables [@ms-learn-sentinel-custom-detections] [@ms-learn-advanced-hunting].

Custom detection rules are rules you can design and tweak using advanced hunting queries. These rules let you proactively monitor various events and system states, including suspected breach activity and misconfigured endpoints. [@ms-learn-sentinel-custom-detections]

That is the policy line that decides where to put a new rule: if your query reads from DeviceProcessEvents (MDE feed), it belongs as an advanced-hunting custom detection inside Defender XDR; if your query reads from Sentinel Event or SecurityEvent (Log Analytics feed), it belongs as a Sentinel analytics rule. The recipe in §10 picks the Sentinel side because the worked example begins in Sysmon, not in MDE -- and Sysmon flows to Log Analytics, not to the MDE advanced-hunting schema.

6.5 Hop 5 -- Microsoft Defender for Cloud as the CWPP alert source

This hop is the most architecturally interesting and the most operationally misunderstood. It is also where the previous iteration of this article had to be corrected on its single most load-bearing detail, so the framing here is deliberate.

Key idea: Only Microsoft Defender for Cloud's CWPP alerts flow into Defender XDR -- not its CSPM posture findings. A Secure Score recommendation that "VMs should have endpoint protection installed" or "Storage accounts should restrict public access" is a posture finding. A "Suspicious PowerShell command line detected on MAL-CONTOSO-PRD-04" emitted by the Defender for Servers runtime plan is an alert. Defender XDR ingests the alerts; the posture findings stay in the MDC blade [@ms-learn-mdc-xdr-concept] [@ms-learn-mdc-xdr-ingest].

The vocabulary first, because everything in this section depends on it.

Continuous assessment of cloud-resource configuration against a baseline of best practices (Microsoft cloud security benchmark, CIS, NIST 800-53, etc.). Output is *recommendations* and a *Secure Score*. CSPM does not see runtime telemetry. In Microsoft's stack, CSPM is the foundational layer of Microsoft Defender for Cloud and is free to enable [@ms-learn-mdc-introduction] [@ms-learn-secure-score]. Runtime detection on a deployed cloud workload -- a VM, a container, a SQL database, a storage account, an App Service. CWPP sees actual events (process spawns, network connections, control-plane API calls) and emits *alerts*. In MDC, CWPP is delivered as paid plans: Defender for Servers, Containers, SQL, Storage, App Service [@ms-learn-mdc-introduction] [@ms-learn-mdc-cwpp-features]. The default CSPM control framework that ships with Microsoft Defender for Cloud. MCSB is Microsoft's interpretation of CIS, NIST 800-53, and PCI DSS controls mapped to Azure, AWS, and GCP resource types. Recommendations are scored against MCSB by default; other frameworks can be added [@ms-learn-mcsb-overview].

The CSPM-versus-CWPP distinction has direct operational consequences for what shows up at hop 6:

What MDC emits	Where it lives	Flows to Defender XDR?
Recommendation (CSPM) -- e.g., "Endpoint protection should be installed"	Recommendations blade in MDC + `SecurityRecommendation` table	No [@ms-learn-mdc-xdr-concept]
Secure Score (CSPM) -- aggregate over recommendations	Secure Score blade in MDC	No [@ms-learn-secure-score]
Compliance assessment (CSPM) -- per-framework rollup	Regulatory compliance blade	No
Alert (CWPP) -- e.g., "Suspicious PowerShell command line"	Alerts blade in MDC + `SecurityAlert` table	Yes [@ms-learn-mdc-xdr-ingest]
Container runtime alert -- e.g., "Web shell detected in pod"	MDC Alerts + `SecurityAlert`	Yes [@ms-learn-mdc-containers]
Storage runtime alert -- e.g., "Anomalous access from Tor IP"	MDC Alerts + `SecurityAlert`	Yes [@ms-learn-mdc-storage]

The CWPP alerts come from MDC's five priced runtime plans. Each plan has its own data path, but they all converge on the same SecurityAlert table in Log Analytics and on the same XDR ingestion path:

MDC plan	Workload	Data source	Reference
Defender for Servers	Windows / Linux VMs, Arc	MDE sensor + agent telemetry	[@ms-learn-mdc-defender-servers] [@ms-learn-mdc-mde-integration]
Defender for Containers	AKS, EKS, GKE pods	runtime sensor + Kubernetes audit	[@ms-learn-mdc-containers]
Defender for SQL	Azure SQL, Arc SQL	Azure SQL Advanced Threat Protection signals	[@ms-learn-mdc-sql] [@ms-learn-azuresql-atp]
Defender for Storage	Storage accounts	Control plane + blob access patterns	[@ms-learn-mdc-storage]
Defender for App Service	App Service apps	Process + network signal from the worker	[@ms-learn-mdc-appservice]

For the worked example, the relevant plan is Defender for Servers. Because MDE is installed on the host (Defender for Servers Plan 2 includes the MDE license), the MDE sensor's runtime telemetry feeds into MDC's detection engine and emits the Suspicious PowerShell command line MDC alert at 14:07:42 UTC [@ms-learn-mdc-mde-integration] [@ms-learn-mde-onboard-windows]. That alert flows to Defender XDR via the MDC-to-XDR alert-ingestion integration that reached general availability in March 2024 (specifically March 13, 2024) [@ms-learn-mdc-xdr-ingest] [@ms-learn-mdc-xdr-concept].

Note: Do not assume MDC posture findings will appear in your Defender XDR incident. The MDC-to-XDR integration ingests alerts only, not recommendations and not Secure Score deltas. If a SOC analyst wants posture context on an incident-affected host (e.g., "was this host's endpoint protection missing per Secure Score?"), they must pivot to the MDC blade or join SecurityRecommendation from KQL. There is no automatic incident-side enrichment for posture findings as of the documented integration scope [@ms-learn-mdc-xdr-concept] [@ms-learn-mdc-xdr-ingest].

The CSPM/CWPP separation also explains the multi-cloud story. MDC's CSPM scope spans Azure, AWS, and GCP via cloud connectors -- you can onboard an AWS account with aws-onboarding and see your S3 buckets in the Secure Score [@ms-learn-mdc-onboard-aws]. The CWPP plans for non-Azure clouds are narrower: Defender for Servers works on AWS EC2 and on-prem via Azure Arc, Defender for Containers works on EKS and GKE, but several plans (Storage, App Service) are Azure-only. The result is a posture surface that is genuinely multi-cloud and a runtime surface that is mostly Azure-plus-Arc -- which is the layer that actually flows to XDR at hop 6 [@ms-learn-mdc-introduction].

6.6 Hop 6 -- The Defender XDR correlation engine and the fan-in

The last hop is the merge. The Defender XDR correlation engine reads incoming alerts from all source pipelines, normalizes the entity values they carry, and groups alerts whose entities overlap within a sliding time window into a single incident. The grouping is asymmetric: a higher-confidence alert (e.g., an MDE process-tree alert with a strong ProcessGuid) can pull in lower-confidence alerts (e.g., a Sentinel rule whose only entity is Host), but not vice-versa [@ms-learn-xdr-correlation].

The server-side service that reads alerts from connected sources, computes entity overlap and temporal proximity, and merges related alerts into incidents. The engine is not user-configurable in detail; merge thresholds, time windows, and entity-priority rules are Microsoft-managed defaults [@ms-learn-xdr-correlation] [@ms-learn-defender-xdr-incidents].

The geometry of the fan-in for the worked example is the mirror image of the fan-out in section 5. The same three alerts that arrived at three different timestamps now converge on a single incident object I-7842:

sequenceDiagram autonumber participant SEN as Sentinel SecurityAlert participant MDC as MDC SecurityAlert participant MDE as MDE DeviceAlertEvents participant COR as Defender XDR correlator participant INC as Incident I-7842 SEN->>COR: Host MAL-... ProcessGuid abc at 14:05:04 MDC->>COR: Host MAL-... File powershell.exe at 14:07:42 MDE->>COR: Host MAL-... ProcessGuid abc at 14:08:11 Note over COR: match window ≤ 30 min COR->>INC: open incident, attach Sentinel alert COR->>INC: merge: MDE matches on ProcessGuid COR->>INC: merge: MDC matches on Host within window INC-->>SEN: backlink to source alert INC-->>MDC: backlink to source alert INC-->>MDE: backlink to source alert

Three things deserve explicit attention in this fan-in:

The strong-entity priority. The MDE alert and the Sentinel alert share ProcessGuid. Microsoft documents that field as a unique value designed to make event correlation easier across hosts and domains [@ms-learn-sysmon]. The merge between them is unambiguous. The MDC-from-Servers alert only carries Host and File -- the MDC plan's alert grammar does not necessarily emit ProcessGuid even though the underlying MDE sensor knows it. The MDC alert merges into the incident on the weaker Host match within the time window.
The Microsoft-managed thresholds. The correlation window, the entity-priority rules, and the merge logic are not exposed for customer tuning. They are documented at the policy level -- "alerts that share entities within a time window" -- but the exact heuristics are part of the Defender XDR service [@ms-learn-xdr-correlation]. §9 returns to this opacity as an open problem.
What does NOT merge. Some categories of source data stay outside the incident graph even when they ought to: cross-workspace Sentinel rules (alerts in a workspace other than the Defender-XDR-connected "primary" one), third-party connector alerts that lack entity mappings, and -- as already underlined -- MDC posture findings of every kind [@ms-learn-mdc-xdr-concept].

The "primary workspace" constraint matters for multi-workspace customers. A Defender XDR tenant connects to exactly one Sentinel primary workspace for the unified secops experience. Sentinel alerts from secondary workspaces still exist as alerts, can still trigger automation rules, and are still queryable via cross-workspace KQL -- but they do not appear in the unified incident graph at security.microsoft.com [@ms-learn-unified-secops] [@ms-learn-move-to-defender]. Customers with regional workspace topologies (e.g., one per Azure region for data-residency reasons) need to plan which workspace is the XDR-connected one.

For the worked example, hop 6 completes at 14:09:30 UTC: the SOC analyst sees a single incident in their queue, titled Multi-stage incident on one endpoint, with three correlated alerts on its alerts tab, a unified entity graph showing the host, the user, the parent and child processes, the file hash, and the URL embedded in the encoded command line, and one-click pivots to the MDE timeline, the Sentinel investigation graph, and the MDC alert detail. Three pipelines, one analyst surface, nine minutes thirteen seconds end-to-end.

That is the full path. The next three sections compare it to what other vendors do, name the theoretical limits any such pipeline has to live with, and walk the open problems that even the best-tuned version of this pipeline still faces.

7. Competing approaches: inside and outside the Microsoft fence

The architecture in §6 is one answer to "how do I turn endpoint telemetry into a SOC incident." It is not the only answer. Other detection engines exist both inside Microsoft and outside, with materially different design choices that are useful to compare side-by-side.

Inside Microsoft, six detection engines run on roughly the same data over the same workspace -- and an architect picking where to put a new detection has to know what each one optimizes for.

Engine	Where the query runs	Latency	Best fit
Sentinel scheduled rule	Log Analytics KQL, every 5+ min	5-8 min	Cross-source SIEM detections, free-form KQL [@ms-learn-sentinel-scheduled-rules]
Sentinel NRT rule	Log Analytics KQL, every 1 min	1-2 min	High-priority single-row detections [@ms-learn-sentinel-nrt-rules]
Sentinel Fusion	ML, multi-source	Hours	Multistage attack patterns, low-signal corroboration [@ms-learn-sentinel-fusion]
Defender XDR custom detection	Advanced hunting KQL, periodic	5-30 min	Detections over `DeviceProcessEvents` / MDE schema [@ms-learn-sentinel-custom-detections]
MDE built-in detections	In-product behavioural	Seconds-to-minutes	Endpoint-local process / file / network signatures [@ms-learn-mde-landing]
MDC plan built-in detections	Per-plan engines	Seconds-to-minutes	Per-workload runtime detection (containers, SQL, storage) [@ms-learn-mdc-introduction]

The takeaway is that Sentinel and Defender XDR custom detections are not interchangeable. They read from different schemas (Log Analytics tables vs MDE advanced-hunting tables), they have different governance models (Azure RBAC vs Defender role-based access), and they emit alerts via different paths. The right engine depends on where your telemetry lives. For the worked example, Sysmon in Event is reached by Sentinel, not by Custom Detections; MDE's DeviceProcessEvents for the same host is reached by Custom Detections, not by Sentinel scheduled rules.

Outside Microsoft, the six widely-deployed alternative stacks each make different trade-offs:

Stack	Storage	Query language	Strength	Cost shape
Splunk Enterprise Security	Splunk indexers	SPL	Long-installed, deep app catalog, mature SOAR	License-tier (GB/day) or workload-based
Splunk Cloud + ES	Splunk-managed cloud	SPL	Same SPL, SaaS-managed	Per-ingest workload-priced
Elastic Security	Elasticsearch	EQL + ES	QL	Open-source community, full-text strength
Google SecOps (Chronicle)	Google-internal columnar	YARA-L 2 + UDM	Petabyte-scale retention, fixed bytes-per-employee pricing	Per-employee (no per-GB)
AWS Security Lake + Athena	S3 + OCSF	Athena SQL	Open-schema, bring-your-own-detection	Per-ingest + per-query
Sigma + open-source SIEM	Vendor-neutral rule format, translates to many SIEMs	Sigma YAML	Portable detection rules	Free format; SIEM cost varies

Sigma deserves a special mention because it is a rule format, not a SIEM. Sigma rules describe detections in a vendor-neutral YAML schema and are translated by a converter (sigmac) into the target SIEM's native query language -- KQL for Sentinel, SPL for Splunk, ES|QL for Elastic, YARA-L for Google SecOps [@sigmahq-sigma]. The result is that a single Sigma rule for "Office process spawns PowerShell with encoded command" can be deployed across multiple SIEMs without rewriting. The trade-off is that Sigma compiles to the lowest common denominator of expressiveness; complex multi-table joins do not translate cleanly. Microsoft Sentinel supports Sigma rule import via the analytics-rule wizard [@sigmahq-sigma].

The structural difference that matters most across these stacks is where the storage and query engine live. Splunk on-prem owns its full stack and bills on ingest. Elastic gives you the stack and lets you self-host or buy SaaS. Google SecOps removes the per-GB axis entirely and bills per employee, betting that the value of the SOC is the analyst's time, not the byte count. AWS Security Lake decomposes further than Microsoft does, exposing S3 directly so you can bring any analytics engine. Microsoft's design point -- KQL over Log Analytics with grafted XDR correlation -- sits in the middle: more managed than AWS, more opinionated than Elastic, billed per-GB like Splunk but with separable axes.

There is also a migration option worth knowing about. Microsoft introduced a Sentinel SIEM migration experience in 2024 that uses generative AI to translate detection rules from Splunk SPL to KQL [@ms-learn-sentinel-siem-migration]. The tool is not a complete replacement for human review of every translated rule, but it materially shortens the migration spike that has historically blocked SOCs from switching SIEMs. The existence of such a tool is itself evidence that the SIEM market is becoming more substitutable than it once was -- a SOC's investment in detection logic is no longer locked to one vendor's query language.

For the worked example specifically, every one of the alternative stacks could in principle deliver the same end result -- one incident for a parent-child process-spawn detection. The differences are in the operating model: who owns the storage, who owns the agent, who priced the ingest, and how easily the analyst can pivot from the incident into raw telemetry. Microsoft's pitch with the unified secops platform is that "all of the above are in one portal." The honest reading is "the Microsoft-side ones are in one portal, and the third-party feeds you stream into Sentinel still participate via the same SecurityAlert table."

8. Theoretical limits

The six-hop pipeline is mostly an engineering object. But it inherits a few honestly theoretical limits that no amount of clever product design can defeat. Naming them sharply is the difference between an architect who knows what the system cannot do and a buyer who is surprised.

The general problem of deciding when two records in different data sources refer to the same real-world entity. In the SIEM context, the entities are users, hosts, files, processes, IPs, URLs, and email recipients. Strong identifiers (a hardware-rooted DeviceId, a Microsoft Entra ObjectId, a SHA256 hash) make the problem tractable; weak identifiers (an account name, an IP address, a file name) make it probabilistic [@ms-learn-sentinel-entities].

The first hard limit is that entity resolution across pipelines is structurally probabilistic whenever the strong identifiers are missing. The Defender XDR correlator depends on entity overlap; the worked example merged cleanly because ProcessGuid was shared between MDE and Sentinel. Take that identifier away and the merge falls back on Host, which is shared but ambiguous (hostnames are reused, machine accounts get recycled), and ultimately on weaker identifiers like file name or command-line substring. The table below names what identifiers each source pipeline can be relied upon to carry.

Entity type	Strong identifier (when available)	Weak fallback	Pipelines that emit the strong form
Host	DeviceId (MDE GUID), Azure resourceId	Hostname, FQDN	MDE, MDC for Servers, Sentinel (if mapped)
Process	ProcessGuid (Sysmon/MDE)	Image path + start time	Sysmon, MDE, advanced hunting
Account	Microsoft Entra ObjectId	UPN, samAccountName	Microsoft Entra ID logs, MDI
File	SHA256	Filename, MD5	MDE, Sentinel rules that include hash
IP	n/a (probabilistic by definition)	IP literal	All
URL	Normalized URL with scheme	Bare host	MDE, Defender for Office, threat-intel feeds

Note: Aha #3 -- entity resolution is information-theoretic, not engineering. Two records refer to the same entity if and only if their identifiers carry enough joint information to pick that entity out of the space of all entities. When the entity space is small (a few thousand hosts) and the identifier is strong (a DeviceId), the match is determined. When the entity space is large (every IP on the public internet) and the identifier is weak (the bare IP), the match is probabilistic and false-positives accumulate. No correlation engine, however clever, can manufacture information that the source pipeline did not record. The architectural lesson is to invest in strong identifiers upstream -- in agents, in DCR schemas, in alert grammars -- not to lean on correlator cleverness downstream.

The second hard limit is normalization lossiness. ASIM (Advanced Security Information Model), Microsoft's effort to normalize Sentinel data into common schemas like _Im_ProcessCreate, makes cross-source queries dramatically easier -- but the normalization is lossy. Fields that exist only in Sysmon (such as the Sysmon-specific IntegrityLevel value, or the OriginalFileName from the PE manifest) get dropped on the way into the normalized schema [@ms-learn-sentinel-asim-normalization]. The trade-off is honest and inescapable: a normalized schema is a projection from a richer per-source schema, and projections lose data by construction.

We can sketch this formally. If $$S$$ is the per-source schema (a set of fields), $$N$$ is the normalized schema, and $$\pi: S \to N$$ is the projection (the ASIM mapping), then the information loss on a single record $$r$$ is

$$ L(r) = H(r) - H(\pi(r)) $$

where $$H$$ is the entropy (number of bits) of the record. For a Sysmon ProcessCreate row, $$H(r)$$ is roughly $$\log_2 |S|$$ bits over a thirty-field schema (call it ~150-200 bits of effective entropy after compression of correlated fields); $$H(\pi(r))$$ is around half that after mapping into the much smaller normalized _Im_ProcessCreate schema. The dropped bits are exactly the fields you cannot query in the normalized form. ASIM is good for cross-source detections that need only common fields; per-source detections that need the long tail of source-specific fields must query the raw source table directly.

The third limit is temporal alignment. Each pipeline has its own clock: Sysmon timestamps come from the host kernel, MDC alerts from the MDC service back-end, Sentinel TimeGenerated from the workspace ingestion. Within a single host these clocks are usually close (NTP-synced), but across hosts and across pipelines they can drift by seconds or minutes. The correlator's "within a time window" merge has to tolerate this drift, which means the window has to be larger than the worst-case clock skew. A larger window means more false-positive merges. There is no way out of this trade-off; only operational tuning between sensitivity and specificity.

The fourth limit is rule expressiveness ceiling. KQL is Turing-complete in the sense that any computable detection can be expressed if you are willing to write enough of it -- but Sentinel scheduled rules cap query duration, query result size, and join cardinality. Detections that conceptually want to scan a year of data and join against a separately-changing IOC list are expressible in KQL but not runnable under Sentinel rule limits. Custom ADX clusters or Spark-on-Synapse can run such queries, at the cost of leaving the unified portal entirely.

These are the limits any honest architecture has to live with. The Microsoft pipeline does well on the first (when strong identifiers exist), is honest about the second (ASIM is documented as a normalization, not a transparent overlay), tolerates the third (windowed merge), and surfaces the fourth as a Sentinel pricing-and-scope conversation. None of them is a Microsoft-specific defect. They are properties of the problem.

9. Open problems

The pipeline is fast enough, accurate enough, and -- in the worked example -- correct. It is not finished. Seven open problems remain, in roughly decreasing order of how much they hurt a working SOC today.

1. The Sentinel-Azure-portal cutover is on a hard date. Microsoft has announced the retirement of the Microsoft Sentinel experience in the Azure portal effective March 31, 2027 (extended from the original July 1, 2026 target) [@ms-learn-sentinel-azure-portal-retiring] [@helpnetsec-sentinel-defender-timeline]. After that date, Sentinel can only be operated through the unified Defender portal at security.microsoft.com. The cutover affects analytics-rule authoring (the Azure-portal rule wizard goes away), automation rules, watchlists, and the investigation graph. Customers with custom dashboards, ARM templates, or automation that targets the Azure-portal Sentinel surface must port them. This is the most concrete migration deadline in this article.

2. CWPP-to-XDR coverage is still expanding. As of the documented integration scope, MDC for Servers, Containers, SQL, Storage, and App Service alerts flow to Defender XDR [@ms-learn-mdc-xdr-concept] [@ms-learn-mdc-xdr-ingest]. New CWPP plans (e.g., Defender for APIs as it matures) tend to land first in the MDC blade and only later in the unified incident graph. Customers operationalizing a new MDC plan should check the integration documentation for that specific plan rather than assuming XDR ingestion is automatic.

3. Posture-finding context still lives in a separate blade. As §6.5 established, MDC posture findings do not flow to Defender XDR. A SOC analyst looking at an incident on a host has no incident-side way to see "this host also has a CSPM finding for missing endpoint protection." The workaround is to join SecurityRecommendation against the incident-affected resources via KQL, or to pivot manually to the MDC blade. A first-class "posture context on incident" feature does not exist as of the documented surface area.

4. The correlation engine's heuristics are not user-tunable. The Defender XDR correlation engine merges alerts using a Microsoft-managed set of thresholds: time window, entity priority, confidence weighting [@ms-learn-xdr-correlation]. These are not exposed for customer override. A SOC that wants to widen the merge window (because their telemetry has long ingest tails) or tighten the entity-priority (because they distrust hostname matches for shared-name VMs) has no knob to turn. The correlation behaviour is whatever Microsoft ships; tuning happens by raising support cases against perceived false-merges or false-splits.

5. Custom detection semantics are subtly different from Sentinel rule semantics. A KQL detection authored as a Defender XDR Custom Detection runs over the advanced-hunting schema (DeviceProcessEvents, DeviceFileEvents, etc.), not over Log Analytics tables [@ms-learn-sentinel-custom-detections] [@ms-learn-advanced-hunting]. The two schemas overlap (you can write conceptually similar detections over both), but the field names, the freshness windows, and the result-size caps differ. An organization with parallel teams authoring detections in both surfaces can end up with two near-duplicate detections that drift apart over time. There is no first-class deduplication or "promote this Sentinel rule to a Custom Detection" workflow.

6. Logic Apps write-back from Sentinel to MDC has rough edges. Sentinel automation rules can invoke Logic Apps playbooks to take response actions [@ms-learn-sentinel-logic-apps-playbooks] [@ms-learn-sentinel-soar]. Writing back to MDC -- for example, suppressing an alert in MDC or creating a Defender for Cloud assessment programmatically -- is possible but requires the playbook to call the MDC REST API directly [@ms-learn-mdc-assessments-rest]. There is no native "MDC action" connector with the breadth of the MDE actions connector. Customers building bidirectional response automation between Sentinel and MDC end up writing HTTP-action playbooks by hand. The MDC REST API for assessments lets you create and update assessment results programmatically, but the surface area for writing back to MDC (e.g., dismissing or recategorizing an alert) is smaller than the read API and is not symmetric with Sentinel's native alert-lifecycle actions [@ms-learn-mdc-assessments-rest] [@ms-learn-mdc-custom-recs]. Closing this gap with a first-class connector is on most enterprise customers' wish lists.

7. Multi-workspace and multi-tenant topologies remain awkward. The unified secops experience connects Defender XDR to exactly one Sentinel primary workspace per tenant. Customers with multiple workspaces -- common in regulated industries with data-residency boundaries -- must choose which workspace is the XDR-connected one, and accept that the other workspaces' alerts are visible only inside Sentinel, not in the unified incident graph [@ms-learn-unified-secops] [@ms-learn-move-to-defender]. Multi-tenant MSSPs and customers with subsidiaries on separate Azure tenants face an even harder design problem: there is no single pane across tenants in the unified portal, only the cross-workspace KQL pattern from §4.

8. Multicloud entity resolution: the EC2-on-AWS case. A Windows VM running as an AWS EC2 instance can be brought into Microsoft's stack through two layers, neither of which produces a single shared identifier. Defender for Cloud's multicloud connector ingests AWS CloudTrail and EC2 metadata into MDC's posture surface (CSPM coverage) [@ms-learn-mdc-onboard-multicloud]; Defender for Servers' Arc-based provisioning then installs Azure Monitor Agent and Microsoft Defender for Endpoint on the EC2 host, projecting the box into the Azure tenant's resource graph as an Microsoft.HybridCompute/machines Arc resource. Three identifiers therefore describe the same physical workload but never coincide on a single strong identifier: (1) the EC2 ARN arn:aws:ec2:<region>:<account>:instance/<instance-id>, which is what AWS CloudTrail and the AWS console use; (2) the Arc machine resource ID /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.HybridCompute/machines/<arc-machine-name>, which is what the Log Analytics _ResourceId column carries when AMA forwards the Sysmon event; (3) the MDE DeviceId, a GUID assigned at MDE first-onboarding, which is what the Defender for Servers CWPP alert and the DeviceInfo advanced-hunting table key on. Bridging the three at query time requires bespoke KQL: lift the Arc machine name from _ResourceId via extend ArcMachine = tostring(split(_ResourceId, "/")[-1]), look up the corresponding DeviceId in DeviceInfo keyed by DeviceName, and join to a customer-maintained Watchlist (or external CMDB) that maps Arc machine name -> EC2 instance-id -> EC2 ARN. The pattern works, but every join is a place where the inventory can drift; a renamed EC2 instance or a reimaged host that picks up a new MDE DeviceId will silently break correlation until the watchlist is refreshed.

The EC2 sub-example above is the tip of the iceberg. Multi-cloud is its own open problem and worth a separate article. MDC's CSPM and parts of the CWPP plans (Servers, Containers) cover AWS and GCP via Azure Arc and cloud connectors, but the depth of integration for non-Azure workloads in the unified XDR experience is less than for native Azure workloads. The honest summary is "Azure-first, AWS/GCP-supported, on-prem via Arc." Designs that are AWS-primary should evaluate AWS Security Lake + a SIEM (Sentinel, Splunk, or Athena) against MDC-on-AWS specifically; the choice is not obvious.

None of these problems is fatal to the architecture. Each is the kind of structural friction that comes from grafting three pre-existing pipelines into one analyst surface in fewer than three years. The cutover date is the only one with a deadline; the rest are roadmap items.

10. Recipe: building the pipeline yourself in six steps

This section walks the six setup steps that produce the worked example end-to-end, in the order an engineer should actually do them. Each step names the artifact, the documentation reference, and the single most common mistake that will silently break the step.

Step 1 -- Install Sysmon with a curated configuration

Install Sysmon on the host (Azure VM, Arc-enabled server, or on-prem Windows) with a configuration that emits the events you actually need [@ms-learn-sysmon]. The default Sysmon config is essentially empty; a curated config is what makes it useful. Many teams start with the SwiftOnSecurity sysmon-config or Olaf Hartong sysmon-modular public baselines and prune from there [@swiftonsecurity-sysmon-config] [@hartong-sysmon-modular].

Note: Don't reinvent the Sysmon config. Two community-maintained baselines do most of the work: the SwiftOnSecurity sysmon-config template ("a Sysmon configuration file for everybody to fork...with default high-quality event tracing") and Olaf Hartong's sysmon-modular framework ("a Sysmon configuration repository for everybody to customise") cover the common cases with years of community tuning [@swiftonsecurity-sysmon-config] [@hartong-sysmon-modular]. Pick one, version-control it in your config-management tool (DSC, Ansible, Chef), and ship it via your existing host-config pipeline. The single most common mistake is shipping a default Sysmon install and then wondering why detections fire on noise.

Validate that Sysmon is emitting by reading the local event log on the host: Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 5. If you see ProcessCreate (Event ID 1) records, hop 1 works.

Step 2 -- Deploy the Azure Monitor Agent with a Data Collection Rule

Install AMA on the host (via Azure Policy for Azure VMs, the Arc agent for non-Azure, or the standalone installer) [@ms-learn-ama-overview]. Then create a Data Collection Rule that names the Sysmon channel and ships it to your Sentinel-enabled workspace. The ARM snippet below is the load-bearing artifact: the streams value must be exactly Microsoft-WindowsEvent (or, for the older Event table path, Microsoft-Event), not a variant. This is the silent-failure cliff §6.2 named: get this string wrong and the agent ships nothing, returning no error.

{
  "type": "Microsoft.Insights/dataCollectionRules",
  "apiVersion": "2022-06-01",
  "name": "dcr-sysmon-to-sentinel",
  "location": "eastus",
  "properties": {
    "dataSources": {
      "windowsEventLogs": [
        {
          "name": "sysmonOperational",
          "streams": ["Microsoft-WindowsEvent"],
          "xPathQueries": [
            "Microsoft-Windows-Sysmon/Operational!*[System[(EventID=1 or EventID=3 or EventID=7 or EventID=10 or EventID=11)]]"
          ]
        }
      ]
    },
    "destinations": {
      "logAnalytics": [
        { "name": "lawDest",
          "workspaceResourceId":
            "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.OperationalInsights/workspaces/law-contoso-secops" }
      ]
    },
    "dataFlows": [
      { "streams": ["Microsoft-WindowsEvent"],
        "destinations": ["lawDest"] }
    ]
  }
}

The silent-miss bug is real: a DCR that names "Microsoft-Event" ships into the older Event table; a DCR that names "Microsoft-WindowsEvent" ships into the newer typed WindowsEvent table; a DCR that names anything else (typo, copy-paste from another data source, or a name that does not exist) emits nothing, returns no validation error at deploy time, and produces a silent dashboard hole [@ms-learn-ama-windows-events] [@ms-learn-sentinel-data-connectors-ref]. The fix is to validate post-deploy by checking that rows are arriving in the destination table within ~5 minutes.

Validation KQL to run in the workspace:

Event
| where TimeGenerated > ago(10m)
| where Source == "Microsoft-Windows-Sysmon" and EventID == 1
| summarize count() by Computer

If you see a row per Sysmon-emitting host, hop 2 and hop 3 work.

Step 3 -- Author the Sentinel scheduled analytics rule

Inside the Defender portal's Sentinel section (or the Azure-portal Sentinel blade until the March 31, 2027 cutover), create a new scheduled analytics rule [@ms-learn-sentinel-scheduled-rules] [@ms-learn-sentinel-azure-portal-retiring]. Paste the KQL from the Spoiler in §6.3. Configure entity mappings: Host from Computer, Account from User, Process from ProcessGuid. Schedule: run every 5 minutes over the last 5 minutes. Severity: Medium. Tactic: Execution (MITRE ATT&CK T1059.001).

The single most common mistake at this step is omitting the entity mappings. The rule will fire and produce a SecurityAlert row, but the alert will not participate in cross-pipeline correlation at hop 6 because there are no entities to merge on. Always configure at least Host, Account, and -- when available -- Process or FileHash entity mappings on a Sentinel rule.

This recipe sets up the Sysmon-to-Sentinel-to-XDR path only. Adjacent surfaces -- Microsoft Defender for Office 365 for email alerts, Microsoft Defender for Identity for on-prem AD signals, Microsoft Defender for Cloud Apps (MDCA) for SaaS-app signals -- have their own onboarding paths and are out of scope for this six-step recipe. The convergence point in Defender XDR is the same; the upstream setup differs per source.

Five other adjacent surfaces are worth knowing about as a map of the broader Microsoft SecOps surface, even though this article does not walk any of them:

Sentinel watchlists -- name-value reference tables (e.g., critical-asset inventory, terminated-user list, custom IOC list) stored in the Watchlist table and cached for low-latency enrichment joins in KQL analytics rules and hunts [@ms-learn-sentinel-watchlists].
Sentinel threat intelligence integration -- ingest IOCs from TAXII feeds, Microsoft Defender Threat Intelligence, MISP, or platform connectors into the ThreatIntelligenceIndicator table, and use the built-in TI map rule type to fire on matches against your telemetry [@ms-learn-sentinel-threat-intel].
MSTICPy + Sentinel Jupyter notebooks -- the Microsoft-maintained MSTICPy Python library plus Sentinel's notebook integration give hunters a programmable workspace for incident investigation, IOC pivoting, and ML-driven analysis on Sentinel data outside the rule-authoring surface [@ms-learn-sentinel-notebooks].
Sentinel Content Hub and the solutions marketplace -- the in-product distribution surface for prepackaged detections, parsers, workbooks, hunting queries, and playbooks delivered as Microsoft-signed or partner-signed solutions [@ms-learn-sentinel-solutions].
Microsoft Defender External Attack Surface Management (Defender EASM) -- the adjacent posture surface that discovers and maps an organization's internet-facing assets from the outside-in; explicitly out of scope for this article's CSPM/CWPP/SIEM/XDR spine, but worth knowing exists [@ms-learn-defender-easm].

Step 4 -- Enable Defender for Servers (Plan 2) for MDC alerts

On the Azure subscription that owns the VM (or the Arc-enabled resource group), enable Microsoft Defender for Cloud's Defender for Servers Plan 2 [@ms-learn-mdc-defender-servers]. Plan 2 includes the MDE license and the runtime detection engine that emits the MDC alert at hop 5. Enabling the plan automatically deploys MDE to the in-scope hosts and configures the MDC-to-XDR alert-ingestion integration that reached general availability in March 2024 [@ms-learn-mdc-mde-integration] [@ms-learn-mdc-xdr-ingest].

Validation: trigger a benign test pattern (e.g., powershell -EncodedCommand of a harmless script) on a test host. Within ~5 minutes, you should see an MDC alert in the MDC Alerts blade titled Suspicious PowerShell command line (or similar), and a corresponding alert in security.microsoft.com.

Step 5 -- Connect Sentinel to the unified Defender portal

Inside the Defender portal, enable the Sentinel connection that designates your Log Analytics workspace as the primary workspace for the unified secops experience [@ms-learn-sentinel-defender-portal] [@ms-learn-move-to-defender]. This step is what makes the Sentinel SecurityAlert rows flow into the Defender XDR incident graph at hop 6 and become merge candidates with the MDC and MDE alerts.

One-tenant, one-primary-workspace constraint: as §6.6 noted, a Defender XDR tenant has exactly one primary Sentinel workspace. If you have multiple workspaces (regional residency reasons, MSSP topology, etc.), choose deliberately which one is the XDR-connected one. Alerts in secondary workspaces remain queryable via Sentinel but do not participate in the unified incident graph.

Step 6 -- Write a watchdog rule that fires on telemetry silence

The pipeline can fail silently in multiple places: AMA stops on a host, the DCR is removed or mis-edited, Sysmon is uninstalled, the workspace fills its daily cap. None of these failures produce an alert by themselves. Write a Sentinel scheduled rule that fires when expected telemetry is absent: for each host in your inventory, alert if Event table rows from that host stop appearing for more than N minutes.

{`# Run via Azure Monitor REST API or the az monitor cli; here we simulate # the comparison logic that an analytics rule would express in KQL.

EXPECTED_INVENTORY = { 'MAL-CONTOSO-PRD-01', 'MAL-CONTOSO-PRD-02', 'MAL-CONTOSO-PRD-03', 'MAL-CONTOSO-PRD-04', 'MAL-CONTOSO-PRD-05', }

In a real deployment this list comes from KQL against the Event table: Event | where TimeGenerated > ago(24h) | summarize by Computer

RECENTLY_EMITTING_HOSTS = { 'MAL-CONTOSO-PRD-01', 'MAL-CONTOSO-PRD-02', # PRD-03 absent: agent down? DCR removed? 'MAL-CONTOSO-PRD-04', 'MAL-CONTOSO-PRD-05', }

silent_hosts = EXPECTED_INVENTORY - RECENTLY_EMITTING_HOSTS if silent_hosts: print(f"ALERT: telemetry silence on {len(silent_hosts)} host(s):") for h in sorted(silent_hosts): print(f" - {h}") else: print("OK: all expected hosts emitted Sysmon events in the last 24h.") `}

The equivalent in Sentinel is a scheduled rule that joins a static Watchlist of expected hosts against Event | summarize by Computer over the last 24 hours and alerts on the set difference. This watchdog is the only thing standing between an architectural diagram of perfect convergence and the operational reality of one host's silent agent.

This recipe addresses detection-and-response only. Compliance framing -- mapping detections to MITRE ATT&CK tactics, mapping posture findings to MCSB controls, reporting against PCI-DSS or NIST 800-53 -- is a separate concern handled by MCSB and the MDC regulatory-compliance blade [@ms-learn-mcsb-overview]. Most enterprise SOCs end up doing both, but a working detection pipeline can ship without the compliance layer attached.

With these six steps the Sysmon record from §1 reaches security.microsoft.com in roughly nine minutes, three alerts merged into one incident. The pipeline is real. The next section addresses the questions that show up in every architecture-review meeting once the pipeline is built.

11. FAQ

It depends on whether you need a SIEM. MDE alone gives you endpoint detection, response actions on the endpoint, and a native incident view inside Defender XDR. It does not give you a place to ingest non-endpoint log sources (firewall, identity provider that is not Microsoft Entra, custom application logs) and run cross-source correlation against them. Sentinel is the SIEM substrate that does that [@ms-learn-mde-landing] [@ms-learn-sentinel-overview]. A small organization whose telemetry is entirely MDE-and-Microsoft-365 can run without Sentinel; one whose threat model includes anything outside that envelope generally needs it. No. As §6.5 established and as the Microsoft documentation is explicit about, only MDC's **CWPP alerts** (from Defender for Servers, Containers, SQL, Storage, App Service plans) flow into the Defender XDR incident graph [@ms-learn-mdc-xdr-concept] [@ms-learn-mdc-xdr-ingest]. CSPM-side artifacts -- recommendations, Secure Score deltas, regulatory-compliance findings -- stay in the Microsoft Defender for Cloud blade. If you want posture context attached to an incident, you have to pivot manually to MDC or join `SecurityRecommendation` against the incident's affected resources via KQL. For the documented Sysmon-to-Sentinel-to-XDR path: roughly 5 to 10 minutes typical. The dominant factor is the Sentinel scheduled-rule cadence (minimum 5 minutes) [@ms-learn-sentinel-scheduled-rules]. NRT rules cut it to 1-2 minutes for single-row matches [@ms-learn-sentinel-nrt-rules]. MDE's native path through Defender XDR is sub-minute for the endpoint detection itself; the cross-pipeline merge happens in the correlation engine within a sliding window after the slowest pipeline reports. Don't promise sub-minute for the SIEM path; do promise sub-minute for the EDR-direct path. Because each pipeline names hosts in its own grammar. MDE uses a `DeviceId` (a Microsoft-generated GUID). Sentinel uses `Computer` (the hostname as Windows reports it). MDC uses the Azure `resourceId` for the underlying VM. Microsoft Entra ID uses a directory `ObjectId`. The Defender XDR correlation engine normalizes these where it can [@ms-learn-xdr-correlation] [@ms-learn-sentinel-entities], but in raw KQL queries you have to `join` across the identifier spaces explicitly. The `IdentityInfo` and `DeviceInfo` tables are the join helpers; the entity-resolution problem from §8 is what makes this non-trivial. **March 31, 2027** (extended from the original July 1, 2026 target). After that date, Microsoft Sentinel can only be accessed via the unified Defender portal at `security.microsoft.com` [@ms-learn-sentinel-azure-portal-retiring] [@helpnetsec-sentinel-defender-timeline]. Customers with custom dashboards, automation, or ARM templates targeting the Azure-portal Sentinel surface need to plan migration. The underlying Log Analytics workspace and KQL queries do not change; the analyst UI does. It depends on where your telemetry lives. **Sentinel scheduled rules** read from Log Analytics tables (`Event`, `SecurityEvent`, `Syslog`, custom tables) and are the right answer when your detection covers data ingested via DCRs or Sentinel connectors. **Defender XDR Custom Detections** read from the advanced-hunting schema (`DeviceProcessEvents`, `DeviceFileEvents`, `EmailEvents`, etc.) and are the right answer when your detection covers MDE / Defender for Office / Defender for Identity-native telemetry [@ms-learn-sentinel-custom-detections] [@ms-learn-advanced-hunting]. The two are not interchangeable; the field names and result-size caps differ. A common operational pattern is "Sentinel for everything Sysmon and third-party, Custom Detections for everything MDE-native." Partially, and only by hand. Sentinel automation rules invoke Azure Logic Apps playbooks, and those playbooks can call the Microsoft Defender for Cloud REST API directly to take actions like creating an assessment or (with limited surface area) acknowledging an alert [@ms-learn-sentinel-logic-apps-playbooks] [@ms-learn-mdc-assessments-rest] [@ms-learn-mdc-custom-recs]. There is no first-class "MDC alert action" Logic Apps connector with the same breadth as the MDE connector. Customers building bidirectional Sentinel-MDC response automation write HTTP-action playbooks against the MDC REST API and accept that the integration is less native than the MDE side.

From `cmd.exe` to a Kusto Row in 90 Seconds: How Sysmon and Defender for Endpoint Actually Work

noreply@paragmali.com (Parag Mali) — Wed, 13 May 2026 00:00:00 GMT

Modern Windows EDR is a seven-layer production pipeline. A kernel callback fires, a user-mode aggregator labels the event, an ETW publisher (Sysmon) or a TLS-pinned cloud forwarder (`SenseCncProxy.exe`) ships it, and within seconds the event surfaces as a row in a Kusto table that the analyst queries with KQL. Sysmon (Russinovich and Garnier, August 2014) is the configurable kernel-callback-then-publish reference: twenty-nine event IDs, three canonical configurations (SwiftOnSecurity, the post-rename `NextronSystems/sysmon-config`, and `olafhartong/sysmon-modular`), Antimalware-PPL hardening since v15 in June 2023. Microsoft Defender for Endpoint (Windows Defender ATP preview March 2016, MDE rename September 2020, Microsoft Defender XDR portal late 2023) is the commercial cloud-correlated counterpart: `MsSense.exe` runs as Antimalware-PPL, shares the `WdFilter.sys` / `WdBoot.sys` / `WdNisDrv.sys` Defender Antivirus kernel surface, and lands events in six `Device*` Advanced Hunting tables with 30-day in-portal retention, extended via the Microsoft Sentinel Defender XDR connector. For MDE-licensed shops with a detection-engineering team, the community pattern is Hartong's `sysmonconfig-mde-augment.xml` -- Sysmon as a complement, not a duplicate. The pipeline's four structural ceilings (pre-driver-load horizon, observation-vs-enforcement latency, MDE schema truncation, kernel-mode adversary primitive) are documented and unclosed; FalconForce's 2022 CVE-2022-23278 disclosure and InfoGuard Labs' 2025 certificate-pinning bypass bookend an adversarial arc the field has not yet ended.

1. From `cmd.exe` to a Kusto Row in Ninety Seconds

At 9:14 a.m. on a Monday, a SOC analyst named Maya watches a DeviceProcessEvents row light up in the Advanced Hunting console of Microsoft Defender XDR. The FileName is powershell.exe. The ProcessCommandLine reads powershell.exe -enc JABzAD0A.... The InitiatingProcessFileName is WINWORD.EXE. The Timestamp is three seconds ago [@deviceprocessevents-table].

By 9:15:44 Maya has pivoted to DeviceNetworkEvents, found an outbound connection from the same InitiatingProcessId to a previously-unknown IP on TCP/443, clicked Isolate device in the device page, and the endpoint is off the network. Ninety seconds, end to end. Email triage of the original message; a quarantine on the inbound .docm; and -- by the time the user's coffee has cooled -- a brand-new IOC in the tenant's custom indicator list.

This article is the rewind. We walk Maya's ninety seconds backwards through the seven pipeline layers that made the triage possible -- starting in ring zero, ending in the KQL query you can copy into your own tenant -- and along the way we answer the question every SOC manager has asked at least once: do we deploy Sysmon alongside Defender for Endpoint, or trust Defender alone?

The seven layers

Maya is looking at a single Kusto row. Behind that row sit seven distinct software components, each of which can fail independently:

A kernel callback fired inside the nt!PspInsertProcess path on the target machine the instant WINWORD.EXE called CreateProcessW to spawn powershell.exe. The callback handler lives inside WdFilter.sys (Defender Antivirus's filter driver) and inside SysmonDrv.sys if Sysmon is also installed [@pssetcreateex-msdn].
A user-mode aggregator -- MsSense.exe for Defender for Endpoint, or Sysmon.exe (the service) for Sysmon -- received the structured callback notification, enriched it with parent-process state, file hashes, signature information, and identity data, and decided whether the event was worth shipping [@mde-ms-learn][@sysmon-ms-learn].
An ETW publisher -- in Sysmon's case the Microsoft-Windows-Sysmon provider -- emitted the event to the operating system's tracing bus, and the Sysmon service wrote it to the Microsoft/Windows/Sysmon/Operational event log [@sysmon-ms-learn].
A cloud forwarder -- SenseCncProxy.exe -- ran the Defender payload through TLS with certificate pinning out to the regional Defender XDR ingest endpoint [@falconforce-2022].
A cloud sensor pipeline in Microsoft's regional datacenter (the US for US tenants, the EU for European tenants, the UK for UK tenants) wrote the event into the Advanced Hunting Kusto cluster [@advanced-hunting-overview][@ms-server-endpoints-learn].
A Kusto table -- DeviceProcessEvents -- became queryable within seconds, joined logically across roughly fifty columns to its siblings (DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceImageLoadEvents, DeviceEvents) [@deviceprocessevents-table].
A KQL query Maya wrote, or one of Microsoft's built-in detection rules, joined the process row to the network row on (DeviceId, InitiatingProcessId), surfaced the C2 callback inside a ninety-second window, and put the device-isolation button on her screen [@advanced-hunting-overview][@sentinel-xdr-connector].

Each of these seven layers is independently failure-prone. Operating an EDR well -- which is what this article is about -- means knowing which layer produced which artifact, which layer can be tampered with, and which layer is the right one to fix when the row does not arrive.

Key idea: Modern Windows EDR is a seven-layer production pipeline: kernel callback, user-mode aggregator, ETW publisher (or cloud forwarder), TLS-pinned cloud transport, regional Kusto ingest, table write, KQL read. Sysmon and Microsoft Defender for Endpoint are two implementations of the same seven layers, with different design philosophies at every layer.

Why two products, not one

Sysmon and Defender for Endpoint were not designed as a pair. They evolved as competing answers to the same problem -- when prevention fails, what evidence do you give the responder? -- on the same operating system, with the same kernel-callback APIs underneath, and with the same Windows Event Tracing bus as the transport layer in the middle. They converged on a shared trust model only in 2023, when both products began running as protected processes [@sysmon-ms-learn][@falconforce-2022].

That convergence is not coincidence. It is the consequence of a decade of architectural pressure pushing both products toward the same answer: collect at the Microsoft-sanctioned kernel-callback boundary, normalize in user mode, ship over a tamper-resistant transport, and surface to the analyst as a queryable column family. The differences are in the configuration grammar, the cloud-side enrichment, and the trust boundary at the publisher edge. The seven layers are the same. To see why, we have to start in 2014, when Sysmon shipped with three event types.

2. Twelve Years, Two Arcs, One Convergence

Anton Chuvakin, then a research VP at Gartner, named the category in July 2013. His blog post -- preserved on his personal site after Gartner deleted its analyst blogs in late 2023 -- coined the term Endpoint Threat Detection and Response (ETDR) and defined it as "tools primarily focused on detecting and investigating suspicious activities (and traces of such) other problems on hosts/endpoints" [@chuvakin-2013][@wikipedia-edr]. The "T" dropped out of the acronym within eighteen months and the field has been called EDR ever since.

Chuvakin's question -- what evidence do you give the responder when prevention fails? -- got two different answers from inside Microsoft over the next decade. One was free, configurable, and ran on every Windows machine the operator wanted to run it on. The other was commercial, cloud-correlated, and only worked if you paid for it. Both started in the same place: at the supported kernel-callback boundary that Microsoft had been steadily building out since Windows XP.

The Sysmon arc: August 2014 to March 2026

Mark Russinovich gave session HTA-T07R at RSA US 2014 -- Malware Hunting with the Sysinternals Tools -- and the methodology he taught (process-tree pivoting, autoruns enumeration, real-time monitoring of file and registry writes) had a natural conclusion: somebody should ship a Sysinternals tool that did all of that, continuously, into the Windows event log [@russinovich-rsa-2014]. The tool shipped in August 2014, written by Russinovich and Thomas Garnier, also of Microsoft. ZDNet's contemporaneous coverage captured the introduction: "Sysmon, written by Russinovich and Thomas Garnier, also of Microsoft, is the 73rd tool in the set... Note: For public release, Sysmon has been reset to version 1.00" [@zdnet-sysmon-2014]. The launch SKU had three event types: process create (EID 1), file-create-time change (EID 2), and network connect (EID 3).

The design philosophy is captured in a single sentence Microsoft Learn still prints on the Sysmon download page -- a sentence whose framing of Sysmon as a publisher that refuses to do detection and refuses to hide is the entire foundation of the SwiftOnSecurity-NextronSystems-Hartong configuration lineage that §5 unpacks; the verbatim quote lands as the §4 PullQuote [@sysmon-ms-learn]. Every detection-engineering corpus in the Windows field -- SwiftOnSecurity's config, Florian Roth's fork, Olaf Hartong's modular system, the SigmaHQ rule base, the Threat Hunter Playbook -- is downstream of that one design choice.

The version history reads as capability accretion, not architectural change. Sysmon v6 in February 2017 added registry events (EIDs 12-14), process-access (10), file-create (11), pipe events (17-18), file-create-stream-hash (15), and the ServiceConfigurationChange (16) audit of Sysmon's own settings [@sysinternals-blog-v6]. (EID 7 ImageLoad arrived earlier, in Sysmon v2.0 -- the §4 catalogue places it correctly.) Sysmon v10 in June 2019 added DNS-query observation via ETW consumption of Microsoft-Windows-DNS-Client; the v10 release date is recorded in the community-curated Sysmon Version History repository, explicitly marked "Outdated" past v11.10 because its maintainer stopped updating it [@sysmon-version-history]. v13 added ClipboardChange and ProcessTampering. v14 in August 2022 added the first preventive event -- FileBlockExecutable (EID 27) -- making Sysmon something subtly more than a publisher [@diversenok-2022][@hartong-sysmon14-medium].

The architectural inflection landed in June 2023 with Sysmon v15, when the Sysmon service began running as a protected process. BleepingComputer's contemporaneous coverage notes that the service ran as PROTECTED_ANTIMALWARE_LIGHT and the schema bumped to 4.90 with the new FileExecutableDetected event ID 29 [@bleepingcomputer-sysmon15][@hartong-sysmon15-medium]. The Microsoft Learn page now states the change verbatim: "The service runs as a protected process, thus disallowing a wide range of user mode interactions" [@sysmon-ms-learn]. The latest published release at the time of writing is v15.2 on March 26, 2026 (per the Sysmon download page's Published by-line), with twenty-nine event types plus EID 255 (Error) [@sysmon-ms-learn].

The MDE arc: March 2016 to late 2023

Microsoft announced Windows Defender Advanced Threat Protection in a Windows Experience blog post on March 1, 2016 -- "Today, we announce the next step in our efforts to protect our enterprise customers, with a new service, Windows Defender Advanced Threat Protection" [@ms-blog-atp-mar2016]. The service was framed as a cloud-correlated detection-and-investigation layer on top of the Windows 10 sensor, "informed by anonymous information from over 1 billion Windows devices" [@ms-blog-atp-mar2016]. The 2016 product was Windows-only, in-portal, and oriented to detection and investigation only.

The Fall Creators Update in October 2017 broadened the product into prevention: "The Windows Fall Creators Update represents a new chapter in our product evolution as we offer a set of new prevention capabilities designed to stop attacks as they happen and before they have impact. This means that our service will expand beyond detection, investigation, and response, and will now allow companies to use the full power of the Windows security stack for preventative protection" [@ms-blog-atp-jun2017]. Attack Surface Reduction rules, Exploit Guard, and Application Guard joined the platform. So did the Advanced Hunting query surface in 2018 -- KQL on the same Device* tables Maya uses in §1.

The cross-platform reach arrived in March 2019 with macOS support (initially as Microsoft Defender ATP) and was extended to networked Linux and macOS discovery by February 2021 [@securityweek-defender-macos][@bleepingcomputer-defender-linux]. The product was renamed twice. The most-cited rename came at Microsoft Ignite 2020 on September 22, 2020, when the Microsoft Security blog announced the product family rebrand: "Microsoft Defender for Endpoint (previously Microsoft Defender Advanced Threat Protection)" [@ms-unified-siem-xdr-2020]. The same post renamed Microsoft Threat Protection to Microsoft 365 Defender, O365 ATP to Microsoft Defender for Office 365, and Azure ATP to Microsoft Defender for Identity. The second rename was at Microsoft Ignite 2023 in November 2023, when Microsoft 365 Defender became Microsoft Defender XDR, announced as part of the broader product rebrand at Ignite 2023 [@defender-xdr-ms-learn][@ms-ignite-2023-blog].The Ignite 2023 rebrand did not change the KQL substrate, the Device* schema, or the Sentinel connector contract. It is a marketing relabel on top of a stable cloud surface. Detection engineering teams kept writing queries against DeviceProcessEvents exactly as they did the day before the rename.

The configuration-lineage arc

A third arc ran in parallel with the two product arcs: the community-maintained Sysmon configurations that turned Sysmon from a kernel-callback publisher into a deployment-ready detection sensor.

The historical root is SwiftOnSecurity's sysmon-config repository, created on February 1, 2017 per the GitHub REST API [@github-swiftonsecurity-meta]. The README's design intent is succinct: "This is a Microsoft Sysinternals Sysmon configuration file template with default high-quality event tracing" [@github-swiftonsecurity]. The repository remains the most-cited Sysmon-configuration starting point in the SOC industry.

Florian Roth, working under the handle @Neo23x0, forked SwiftOnSecurity's config in January 2018 (the exact creation date is now obscured by a 2021 rename -- see the sidenote below). The fork added blocking-rule support for Sysmon v14, an actively-maintained set of community pull-request merges, and the export-block.xml variant that ships the v14+ FileBlockExecutable rules. The README states the lineage verbatim: "This is a forked and modified version of @SwiftOnSecurity's sysmon config. ... We merged most of the 30+ open pull requests" [@github-neo23x0]. The current maintainer roster lists Florian Roth, Tobias Michalski, Christian Burkard, and Nasreddine Bencherchali.

Olaf Hartong's sysmon-modular was created on January 13, 2018 per the GitHub REST API [@github-hartong-meta]. The repository takes a different design approach: instead of one monolithic XML config, Hartong ships a per-EID-and-per-technique module library that compiles down into one of several pre-generated artifacts -- sysmonconfig.xml (default), sysmonconfig-with-filedelete.xml (default plus archive), sysmonconfig-excludes-only.xml (verbose), sysmonconfig-research.xml (super-verbose, with the warning "really DO NOT USE IN PRODUCTION!"), and the load-bearing sysmonconfig-mde-augment.xml whose entire design intent is to fill the gaps in Defender for Endpoint's collection surface [@github-hartong-modular].Olaf Hartong and Henri Hambartsumyan, the two FalconForce researchers who reverse-engineered Defender for Endpoint in 2022 and surfaced CVE-2022-23278, also maintain olafhartong/sysmon-modular. This is the dual identity that makes the sysmonconfig-mde-augment.xml config uniquely informed: the same people who learned where MDE's collection truncates Sysmon's manifest also published the config that fills those gaps [@falconforce-2022][@github-hartong-modular].

The Neo23x0 repository was renamed in 2021. The current https://github.com/Neo23x0/sysmon-config URL HTTP-301s to https://github.com/NextronSystems/sysmon-config, and the GitHub REST API returns a created_at of 2021-07-24T06:19:41Z with a parent field pointing to SwiftOnSecurity/sysmon-config [@github-nextronsystems-meta]. The content lineage from SwiftOnSecurity is unchanged; only the organizational owner moved from Florian Roth's personal handle to his employer Nextron Systems.

By 2023, then, two product arcs and one configuration arc had converged on the same baseline: kernel callbacks (PsSetCreateProcessNotifyRoutineEx, ObRegisterCallbacks, CmRegisterCallbackEx, Filter Manager minifilters) on the input side; an Antimalware-PPL protected service on the host; an ETW or TLS-pinned cloud transport in the middle; and KQL on Device* tables on the reader side. The convergence was structural, not coincidental. To see why both arcs landed in the same place, we have to start at the kernel-callback boundary -- where Sysmon's input lives.

3. Sysmon Architecture: Kernel Collection, ETW Emission, Event Log Persistence

If you have ever read that Sysmon is an "ETW-based event source," you have read something that is half-true. The half that is right is the output side: Sysmon publishes its events through an ETW provider called Microsoft-Windows-Sysmon, and the rest of the system -- including the Windows Event Log service -- subscribes to that provider. The half that is wrong is the input side. Sysmon does not get most of its raw observations from ETW. It gets them from five kernel-callback families and one Filter Manager minifilter, with two narrow ETW-consumer exceptions (DNS-Client for EID 22; the WMI activity provider for EIDs 19-21).

This distinction is small enough that most blog posts skip it and big enough that getting it wrong leads to architectural confusion. The split between collection (how data enters the Sysmon driver) and emission (how data leaves the Sysmon service) is the first thing to get straight before anything else makes sense.

The in-kernel, low-overhead, manifest-described tracing infrastructure built into Windows since 2000. Providers publish structured events; controllers start trace sessions and select which providers to enable; consumers receive events live or read them from `.etl` files. Sysmon uses ETW as its *output* bus -- its kernel driver hands events to the user-mode service via a private ETW session -- and as a small input source for the DNS-Client kernel provider (EID 22) and the WMI activity provider (EIDs 19-21). A Microsoft-sanctioned ring-0 API for observing operating-system events without patching the System Service Descriptor Table. The Windows kernel exposes a small set of named callback APIs -- `PsSetCreateProcessNotifyRoutineEx` for process create and exit, `PsSetLoadImageNotifyRoutine` for image load (with a `SystemModeImage` bit that distinguishes kernel drivers from user-mode DLLs), `PsSetCreateThreadNotifyRoutineEx` for thread creation (with a remote-thread flag), `ObRegisterCallbacks` for handle-rights filtering against `PsProcessType` and `PsThreadType`, `CmRegisterCallbackEx` for registry operations, and the Filter Manager minifilter framework for file-system I/O. A driver registers a function pointer; the kernel invokes it on the corresponding event with the structured context. PatchGuard tolerates kernel callbacks; it does not tolerate SSDT patching [@wikipedia-kpp][@pssetcreateex-msdn][@ms-wdk-kernel-callbacks]. The file-system filter-driver framework (`FltMgr.sys`) that hosts minifilter drivers between the I/O manager and the file-system stack. Each minifilter declares an *altitude* (a 16-bit priority) and receives notifications for pre- and post-operation hooks on file create, file write, set-information, and set-security. Both `SysmonDrv.sys` and `WdFilter.sys` are minifilters; they coexist at different altitudes without colliding [@sysmon-ms-learn].

Five collection mechanisms, one ETW publisher

The Microsoft Learn page for Sysmon enumerates the event IDs and describes them at the what level; the how (which kernel API actually produced each event) is documented partly in the API references for each callback API and partly in the source code of Sysmon's open Linux port, microsoft/SysmonForLinux, which reuses Sysinternals' shared C++ rule-engine for parsing the same XML schema and translating it onto eBPF instead of kernel callbacks [@github-sysmon-linux][@sysmon-ms-learn]. The Windows port is closed source, but Sysinternals' design has been documented enough -- across the RSA 2014 talk, the Diversenok 2022 reverse-engineering writeup, and the SysmonForLinux source -- that the collection-mechanism inventory is unambiguous.

The five mechanisms are:

Mechanism	API or framework	Sysmon EIDs produced
Process-lifetime callback	`PsSetCreateProcessNotifyRoutineEx`	1 (ProcessCreate), 5 (ProcessTerminate)
Image-load callback	`PsSetLoadImageNotifyRoutine`	7 (ImageLoad); 6 (DriverLoad, distinguished by the `IMAGE_INFO.SystemModeImage` flag on the kernel-mode image)
Thread-creation callback	`PsSetCreateThreadNotifyRoutineEx` (with the `PS_CREATE_THREAD_NOTIFY_FLAG_CREATE_REMOTE` flag in `CREATE_THREAD_NOTIFY_INFO`)	8 (CreateRemoteThread)
Object Manager callback	`ObRegisterCallbacks` against `PsProcessType`	10 (ProcessAccess)
Registry callback	`CmRegisterCallbackEx`	12 (Registry Object Create/Delete), 13 (Registry Value Set), 14 (Registry Key/Value Rename)
Filter Manager minifilter	`FltRegisterFilter` against `FltCreate`/`FltClose`/`FltSetInformation` -- ordinary file system, and the Named Pipe File System (NPFS, `\Device\NamedPipe`) at a different altitude	11 (FileCreate), 15 (FileCreateStreamHash), 17 (PipeEvent Created), 18 (PipeEvent Connected), 23 (FileDelete archived), 26 (FileDeleteDetected), 27 (FileBlockExecutable), 28 (FileBlockShredding), 29 (FileExecutableDetected)

The five-mechanism framing collapses thread-creation and Object Manager callbacks into one architectural family ("process and thread observation via Microsoft-sanctioned callbacks"); a stricter count is six (process-lifetime, image-load, thread-creation, object-handle, registry, minifilter). Either count is defensible; what matters is keeping the API attribution honest: PsSetCreateThreadNotifyRoutineEx is the canonical remote-thread observer, ObRegisterCallbacks(PsProcessType) is the canonical handle-rights filter, and NPFS minifiltering -- not ObRegisterCallbacks -- is what observes named-pipe creation and connection.

The sixth source -- the ETW consumer path -- is special. For DNS queries (EID 22), Sysmon does not register a kernel callback. It subscribes as a consumer of the Microsoft-published Microsoft-Windows-DNS-Client ETW provider, parses the structured DNS events, and republishes them through its own ETW provider with the Sysmon enrichments applied [@sysmon-version-history]. DNS-Client is the only event Sysmon consumes from a Microsoft-published kernel ETW provider; the WmiEvent family (EIDs 19-21) is implemented in a similar consumer style against the WMI activity provider's user-mode tracing surface, which is why the §4 catalogue marks those rows as "WMI ETW provider consumer." Either way, ETW consumption is the input-side exception, not the rule: five kernel-callback families do the bulk of the work, and ETW is the input only for a small, deliberately-chosen set of events.The Sysmon ETW provider has the GUID {5770385F-C22A-43E0-BF4C-06F5698FFBD9}. Microsoft Learn does not enumerate this GUID on the Sysmon page; the authoritative on-host discovery command is logman query providers Microsoft-Windows-Sysmon, which returns the GUID, the keywords mask, and the registered processes. Pavel Yosifovich's community ETW-provider catalogue EtwExplorer mirrors the value [@etwexplorer-sysmon-guid], with the on-host logman command remaining the authority of last resort.

The ProcessCreate path, step by step

The clearest way to see how the pieces fit is to trace one event. Sysmon's process-create handling is the most-quoted EID in the manifest -- it is the EID that produces Maya's row in §1 -- and it follows the canonical kernel-callback pattern that Microsoft codified in PsSetCreateProcessNotifyRoutineEx:

// Conceptual pseudocode for SysmonDrv's process-create path.
// Real Sysmon source for Windows is closed; the Linux port is open.
// This is the contract documented in the WDK reference for
// PsSetCreateProcessNotifyRoutineEx.

NTSTATUS SysmonDrvEntry(PDRIVER_OBJECT DriverObject, ...) {
    // 1. Register the create-process callback. PatchGuard tolerates this.
    PsSetCreateProcessNotifyRoutineEx(SysmonProcessCreateCb, FALSE);
    // ... other callbacks registered similarly ...
    return STATUS_SUCCESS;
}

VOID SysmonProcessCreateCb(
    HANDLE  ParentId,
    HANDLE  ProcessId,
    PPS_CREATE_NOTIFY_INFO  CreateInfo  // NULL on process exit
) {
    if (CreateInfo == NULL) {
        // Process exit: emit EID 5 (ProcessTerminate).
        SysmonEmitEventEID5(ProcessId);
        return;
    }
    // Process create. Apply the XML rule engine: does this process
    // match any <Include> rule, after evaluating <Exclude> overrides?
    if (!SysmonRuleMatch(EID_1, CreateInfo)) {
        return;  // Filtered: produce no event.
    }
    // Enrich with parent process, command line, image hash, integrity
    // level, user SID, ProcessGuid, and session identifiers, then ship
    // through the private Microsoft-Windows-Sysmon ETW publisher.
    SysmonEmitEventEID1(CreateInfo);
}

Four properties of the path matter. First, the callback is invoked synchronously on the thread that issued the CreateProcessW call, before the new process's first instruction runs; the parent and child PIDs are both known, but the new process has not yet executed any user-mode code. Second, the callback is rate-limited only by your rule engine -- there is no built-in throttle, and a verbose <Include> rule on a high-process-turnover host can saturate the ETW session. Third, the callback runs at IRQL = PASSIVE_LEVEL, so it can do file I/O (which the driver needs for hashing) but it must do that I/O carefully to avoid deadlock on the very file system it is monitoring. Fourth, the Sysmon service runs as a separate user-mode process; if the service has crashed or been suspended, the driver continues to emit ETW events into a session with no listener and they evaporate.

Sysmon's per-process unique identifier, formatted as a 128-bit GUID and recorded as the `ProcessGuid` field on every event that names a process. Unlike a Windows process ID, the ProcessGuid survives PID reuse and uniquely identifies a process across its lifetime [@sysmon-ms-learn]; SOC tooling commonly joins on `(DeviceId, ProcessGuid)` to reconstruct process trees and avoid the PID-reuse race condition that plagues raw `ProcessId` joins.

Where the events go

Once the user-mode Sysmon.exe service has labelled the event, it does two things. First, it writes the event to the Windows event log -- specifically to Applications and Services Logs/Microsoft/Windows/Sysmon/Operational per Microsoft Learn's verbatim statement: "On Vista and higher, events are stored in Applications and Services Logs/Microsoft/Windows/Sysmon/Operational" [@sysmon-ms-learn]. Second, the same event is also visible to any ETW real-time consumer subscribed to Microsoft-Windows-Sysmon -- which is how downstream collectors (Windows Event Forwarding, Splunk's universal forwarder, the Elastic Endpoint integration, Wazuh's Windows agent) actually pick the events up, rather than tailing the event log XML.

flowchart LR K1["PsSetCreateProcessNotifyRoutineEx"] --> D[SysmonDrv.sys] K2["PsSetLoadImageNotifyRoutine"] --> D K3["PsSetCreateThreadNotifyRoutineEx"] --> D K4["ObRegisterCallbacks (PsProcessType)"] --> D K5["CmRegisterCallbackEx"] --> D K6["FltRegisterFilter (file system + NPFS)"] --> D K7["ETW consumer: DNS-Client + WMI activity"] --> D D --> P["ETW publisher: Microsoft-Windows-Sysmon"] P --> S[Sysmon.exe service] S --> L["Applications and Services Logs / Microsoft / Windows / Sysmon / Operational"] P --> R["Real-time ETW consumers (WEF, Splunk UF, Wazuh, Elastic)"]

This is the first aha moment. Sysmon is not "ETW based" in the way most blog posts imply. Sysmon is a kernel driver that uses ETW as its IPC bus to user mode, and as a special-case consumer for one provider (DNS-Client). The reason Sysmon needed a kernel driver in the first place is that ETW alone could not see what the kernel callbacks see: ETW could not, in 2014, deliver a synchronous parent-PID-and-image-hash structure at process create time. Sysmon's driver does that work; ETW transports the result.

The protected-process gate added in v15 (June 2023) closed the most-trivial blinding attack -- a SYSTEM-privilege process can no longer issue OpenProcess(PROCESS_TERMINATE) against the Sysmon service to silence it. Raising the bar to a kernel-mode primitive does not eliminate the attack class, but it does change the cost model. The protected-process gate is the architectural inflection that distinguishes pre-v15 Sysmon (trivially blindable) from post-v15 Sysmon (requires a kernel primitive or a BYOVD chain) [@sysmon-ms-learn][@bleepingcomputer-sysmon15].

Five collection mechanisms, one ETW publisher, one event log. That is the input side. Now the catalogue.

4. The Sysmon Event Catalogue: Twenty-Nine IDs and Their Version Gating

Run sysmon -s on any v15.2 host and you get an XML schema enumerating twenty-nine event types plus EID 255 (Error). Every detection-engineering corpus in the field -- SwiftOnSecurity's config, Florian Roth's fork, Hartong's modular, the SigmaHQ rule base, the Threat Hunter Playbook -- is downstream of this single schema [@sysmon-ms-learn][@github-sigma][@github-otrf-thp]. Learn the catalogue once and the rest of the Sysmon toolchain unfolds from it.

A naming disambiguation is worth doing first, because the colloquial event names the field uses (and that the topic input for this article uses verbatim) differ from the canonical Microsoft Learn names. "RegistrySet" is a colloquial pun on RegistryEvent (Value Set), EID 13. "DnsQuery" is a colloquial shorthand for DNSEvent (DNS query), EID 22. "NamedPipeConnect" is two events at once: PipeEvent (Pipe Created), EID 17, and PipeEvent (Pipe Connected), EID 18. The article uses the canonical Microsoft Learn names from here on.

Note: Sysmon's manifest names some events as a family with a parenthetical operation: RegistryEvent (Object create and delete) (EID 12), RegistryEvent (Value Set) (EID 13), RegistryEvent (Key and Value Rename) (EID 14). The same pattern applies to the pipe events: PipeEvent (Pipe Created) (EID 17) and PipeEvent (Pipe Connected) (EID 18). When detection-rule tooling references "EID 12-14" or "EID 17-18", these families are what it means. The colloquial single-name forms used elsewhere in the literature are not wrong; they are just less precise. The MDE schema does not preserve the parenthetical operation suffix; it surfaces these as ActionType values inside DeviceRegistryEvents.

The twenty-nine plus one catalogue

The catalogue groups naturally by the collection mechanism that produces each event:

EID	Canonical name	Collection mechanism	Introduced	Maps to (MDE)
1	ProcessCreate	`PsSetCreateProcessNotifyRoutineEx`	v1.0 (Aug 2014)	`DeviceProcessEvents` (`ProcessCreated`)
2	FileCreateTime	Filter Manager	v1.0 (Aug 2014)	`DeviceFileEvents` (`FileCreated`, partial)
3	NetworkConnect	Internal network-callout	v1.0 (Aug 2014)	`DeviceNetworkEvents` (`ConnectionSuccess`)
4	ServiceStateChange	Sysmon-internal	v1.0 (Aug 2014)	(Sysmon-only)
5	ProcessTerminate	`PsSetCreateProcessNotifyRoutineEx`	v1.0 (Aug 2014)	`DeviceProcessEvents` (`ProcessTerminated`)
6	DriverLoad	`PsSetLoadImageNotifyRoutine` (kernel-mode case via `IMAGE_INFO.SystemModeImage`)	v2.0 (2015)	`DeviceEvents` (`DriverLoad`)
7	ImageLoad	`PsSetLoadImageNotifyRoutine`	v2.0 (2015)	`DeviceImageLoadEvents`
8	CreateRemoteThread	`PsSetCreateThreadNotifyRoutineEx` (with `CREATE_REMOTE` flag)	v3.0 (2016)	`DeviceEvents` (truncated)
9	RawAccessRead	`\Device\Harddisk*` write filter	v3.0 (2016)	(Sysmon-only)
10	ProcessAccess	`ObRegisterCallbacks` (PsProcessType)	v6.0 (Feb 2017)	`DeviceEvents` (GrantedAccess truncated)
11	FileCreate	Filter Manager	v6.0 (Feb 2017)	`DeviceFileEvents`
12	RegistryEvent (Object create/delete)	`CmRegisterCallbackEx`	v6.0 (Feb 2017)	`DeviceRegistryEvents`
13	RegistryEvent (Value Set)	`CmRegisterCallbackEx`	v6.0 (Feb 2017)	`DeviceRegistryEvents`
14	RegistryEvent (Key/Value Rename)	`CmRegisterCallbackEx`	v6.0 (Feb 2017)	`DeviceRegistryEvents`
15	FileCreateStreamHash	Filter Manager	v6.0 (Feb 2017)	(Sysmon-only)
16	ServiceConfigurationChange	Sysmon-internal	v6.0 (Feb 2017)	(Sysmon-only)
17	PipeEvent (Pipe Created)	Filter Manager minifilter on NPFS (`\Device\NamedPipe`)	v6.0 (Feb 2017)	(Sysmon-only)
18	PipeEvent (Pipe Connected)	Filter Manager minifilter on NPFS (`\Device\NamedPipe`)	v6.0 (Feb 2017)	(Sysmon-only)
19	WmiEvent (filter)	WMI ETW provider consumer	v6.10 (mid-2017)	(Sysmon-only)
20	WmiEvent (consumer)	WMI ETW provider consumer	v6.10 (mid-2017)	(Sysmon-only)
21	WmiEvent (consumer-to-filter binding)	WMI ETW provider consumer	v6.10 (mid-2017)	(Sysmon-only)
22	DNSEvent (DNS query)	ETW consumer of `Microsoft-Windows-DNS-Client`	v10.0 (Jun 2019)	`DeviceNetworkEvents` (`DnsQuery`)
23	FileDelete (archive)	Filter Manager	v11.10 (Jun 2020)	`DeviceFileEvents` (partial)
24	ClipboardChange	RDP and Win32 clipboard hooks	v13.0 (2021; disputed)	(Sysmon-only)
25	ProcessTampering	Image-load and `WriteProcessMemory` heuristic	v13.0 (2021; disputed)	(Sysmon-only)
26	FileDeleteDetected	Filter Manager (non-archiving)	v13.30 (2022)	`DeviceFileEvents`
27	FileBlockExecutable	Filter Manager (blocking)	v14.0 (Aug 2022)	(Sysmon-only)
28	FileBlockShredding	Filter Manager (blocking)	v14.10 (2022)	(Sysmon-only)
29	FileExecutableDetected	Filter Manager	v15.0 (Jun 2023)	`DeviceFileEvents`
255	Error	Sysmon-internal	v1.0 (Aug 2014)	(Sysmon-only)

The Sysmon Version History repository's "Outdated" disclaimer ("I didn't find enough time to update this repo - sorry") means the v12 vs v13 boundary for ClipboardChange and ProcessTampering is community-disputed. The canonical Microsoft Learn page does not enumerate version-introduction metadata per event ID. The dates in the table for EIDs 24 and 25 are best-effort community attributions and should be treated as approximate until Microsoft publishes a per-EID version history [@sysmon-version-history][@sysmon-ms-learn].

The design intent, in one sentence

The catalogue exists because Sysmon's design choice -- the one Microsoft Learn still prints today -- explicitly refuses to do detection. The publisher emits structured events; the detection logic is somebody else's problem.

Sysmon does not provide analysis of the events it generates, nor does it attempt to hide itself from attackers.

This is the sentence that explains the entire SwiftOnSecurity-NextronSystems-Hartong configuration lineage [@sysmon-ms-learn]. If Sysmon refuses to do detection, somebody has to write the rules. Three somebodies did, and they wrote three different sets, and the rest of §5 is about the trade-offs between them.

What EID 27 is, and what it is not

The 2022 introduction of FileBlockExecutable (EID 27) was the first preventive event in Sysmon's history. Olaf Hartong's contemporaneous writeup and Diversenok's independent reproduction both describe what the event does, and the mechanism is more subtle than "the I/O is denied." The Sysmon minifilter intercepts the file-handle close operation. If the rule matches and the file content carries an MZ/PE header, Sysmon logs EID 27 and marks the file for deletion via FILE_DISPOSITION_INFORMATION [@diversenok-2022][@hartong-sysmon14-medium]. The attacker's cmd /c copy mimikatz.exe C:\Users\Public\ produces no command-line error. The copy appears to succeed. The file is then deleted at handle-close time. Hartong's writeup captures the user-visible effect verbatim: "*While there is no error on the command line, the file is not written to disk*" [@hartong-sysmon14-medium]. Diversenok's reverse-engineering reads: "*Sysmon monitors and deletes files on closing instead of writing*" [@diversenok-2022]. The closing-time semantics is the structural reason Diversenok's Bypass #1 (split create-close from open-write-close) works at all; the bypass is incoherent under an Access Denied-at-create model and obvious under the close-time-delete model.

This is a confined preventive surface, and it should not be confused with the much larger Defender exploit-protection blocking surface. Defender exploit protection mitigations include arbitrary-code-guard, control-flow-guard enforcement, and ASR rules -- they sit inside the Defender Antivirus and MDE stacks. EID 27's blocking is one Sysmon minifilter making a file-create decision; it is not a general-purpose application-allow-list, and it is not a substitute for Windows Defender Application Control. Hartong's writeup is explicit about the scope -- "the FileBlockExecutable event" -- as is Diversenok's: the introduction reads "the update introduced the first preventive measure -- the FileBlockExecutable event (ID 27)" [@diversenok-2022].

Twenty-nine events, four hardening releases, one schema. The catalogue is only useful if you configure Sysmon to emit subsets of it, and configuration is where the field's three lineages diverged.

5. Three Canonical Sysmon Configurations

Every production Sysmon deployment in the field is forked from one of three repositories. The lineage matters, and one of the things this article fixes is a common attribution error -- "Florian Roth wrote the canonical Sysmon config" is in widespread circulation, but the canonical root is SwiftOnSecurity's repository, and Roth's repo is a 2018 fork of it.

The open-source generic-signature-format authored by Florian Roth and his collaborators at Nextron Systems; the SIEM-and-EDR field's vendor-neutral detection-rule lingua franca. The `SigmaHQ/sigma` repository ships over 3,000 detection rules covering the Windows kernel-callback surface (heavily Sysmon-aware), Linux audit, macOS unified log, AWS CloudTrail, Microsoft 365, and other event sources. Sigma rules are written once and compiled by community converters into the per-tool query languages (KQL for Defender XDR / Sentinel, SPL for Splunk, EQL for Elastic) [@github-sigma].

SwiftOnSecurity/sysmon-config (February 2017)

The historical root. The pseudonymous account SwiftOnSecurity published the first widely-cited Sysmon configuration template on February 1, 2017 per the GitHub REST API [@github-swiftonsecurity-meta]. The README's design intent is the single sentence still printed at the top of the repo: "This is a Microsoft Sysinternals Sysmon configuration file template with default high-quality event tracing" [@github-swiftonsecurity]. The template emphasises clarity over coverage; the XML is heavily commented, and the rule structure follows a deliberately conservative pattern of <Include> blocks per technique.

SwiftOnSecurity's config is the most-cited starting point for Sysmon deployments worldwide and the one that detection-engineering tutorials default to. It is also the parent of every other Sysmon-config repository on GitHub, in the literal GitHub-fork sense -- the GitHub REST API for both NextronSystems/sysmon-config and (via the historical fork-graph) other community configs returns SwiftOnSecurity/sysmon-config as the parent [@github-nextronsystems-meta].

Neo23x0/sysmon-config, now NextronSystems/sysmon-config (January 2018, renamed 2021)

Florian Roth, working under his GitHub handle @Neo23x0, forked SwiftOnSecurity's config in January 2018 and added blocking-rule support for Sysmon v14 plus the merged community pull-request set. The README's design intent reads: "This is a forked and modified version of @SwiftOnSecurity's sysmon config. ... We merged most of the 30+ open pull requests" [@github-neo23x0]. The maintainer roster as of the present writing is Florian Roth (@Neo23x0), Tobias Michalski (@humpalum), Christian Burkard (@phantinuss), and Nasreddine Bencherchali (@nas_bench).

The repository ships a blocking variant, sysmonconfig-export-block.xml, that adds <RuleGroup> blocks targeting EID 27 (FileBlockExecutable) and EID 28 (FileBlockShredding) for the most common malware-staging file paths. This is the variant SOC teams deploy when they want Sysmon's preventive surface to participate in the response pipeline as a hard block rather than as a detection-only artifact.

The legacy URL `https://github.com/Neo23x0/sysmon-config` now HTTP-301 redirects to `https://github.com/NextronSystems/sysmon-config`. The GitHub REST API for the current repository returns `created_at: 2021-07-24T06:19:41Z` with `parent: SwiftOnSecurity/sysmon-config`, which means the repository as it now exists was created in mid-2021 when Florian Roth moved it from his personal handle to his employer's organization namespace [@github-nextronsystems-meta]. The content lineage from SwiftOnSecurity is unchanged; the move is an organizational one. The exact pre-rename creation date of the original `Neo23x0/sysmon-config` repository is not reliably retrievable from the current API and is best dated as January 2018 based on the README and the fork-history.

olafhartong/sysmon-modular (January 13, 2018)

Olaf Hartong's sysmon-modular was created on January 13, 2018 per the GitHub REST API [@github-hartong-meta]. The repository's design takes a different shape from the monolithic SwiftOnSecurity and NextronSystems configs: instead of one carefully-tuned XML, Hartong publishes a per-EID-per-technique module library that compiles into one of five pre-generated artifacts plus an arbitrary number of custom builds [@github-hartong-modular]. The pre-generated variants are:

sysmonconfig.xml -- the default deployment baseline.
sysmonconfig-with-filedelete.xml -- default plus the EID 23 archive variant of file delete, which preserves the deleted file in C:\Sysmon\ (volume-cost trade-off; recommend dedicated drive).
sysmonconfig-excludes-only.xml -- the verbose variant, which captures everything except a small set of well-known exclusions; useful for detection-engineering R&D on a single host.
sysmonconfig-research.xml -- the super-verbose variant, with the README's standing warning: "really DO NOT USE IN PRODUCTION!" -- this is for live-malware-sample analysis in a sandbox, not for fleet rollout.
sysmonconfig-mde-augment.xml -- the variant whose entire design intent is to augment Microsoft Defender for Endpoint's collection surface "to have as little overlap as possible" with what MDE already captures [@github-hartong-modular].

The MDE-augment config is the artifact this article keeps returning to. It is the operational answer -- maintained by a person, not by Microsoft -- to the question of which Sysmon events are worth collecting on a host that already has MDE installed. We will return to its specific contents in §10. For now, the key observation is that this config exists because of a documented absence: Microsoft has not published a per-ActionType cross-walk between MDE's Device* schema and Sysmon's manifest, so Hartong reverse-engineered one.

Side-by-side comparison

Dimension	SwiftOnSecurity/sysmon-config	NextronSystems/sysmon-config (formerly Neo23x0)	olafhartong/sysmon-modular
Author / org	SwiftOnSecurity (pseudonymous)	Florian Roth + Nextron Systems team	Olaf Hartong (and FalconForce collaborators)
Created	Feb 1, 2017	Forked Jan 2018; renamed Jul 24, 2021	Jan 13, 2018
Distribution	One monolithic XML	Two XMLs (audit + blocking)	Modular per-technique + five pre-generated builds
Design philosophy	Quality starting point, conservative	Community-maintained, blocking-aware	Tunable modular, MITRE ATT&CK-mapped
Best used for	First-time Sysmon deployment	Standalone Sysmon at scale	Sysmon alongside MDE, or per-team customization
Pre-generated v14+ blocking	No (audit only)	Yes (`sysmonconfig-export-block.xml`)	Yes (built from blocking modules)
MDE coexistence variant	No	No	Yes (`sysmonconfig-mde-augment.xml`)

Choosing among the three

The detection-engineering trade-off framing is short. Pick SwiftOnSecurity when you want a clean, well-commented starting point and you are not yet sure which events you actually need. Pick NextronSystems when you want a community-maintained baseline that already has the blocking rules for Sysmon v14+. Pick Hartong when you want fine-grained per-technique tunability or, more commonly, when you are running MDE and need Sysmon to augment rather than duplicate it.

Tactical caution worth one inline note: Sysmon supports one active configuration at a time. There is no aggregate-multiple-XMLs feature at the driver layer. Hartong's modular approach generates a single merged XML at build time; the production fleet receives that single XML and the driver enforces it. If you are trying to run two configurations side by side -- one for the SOC's hunting, one for the platform team's audit -- pick one, merge the rules, and ship the combined product. The deployment tooling in sysmon-modular is built around exactly this constraint.

All three configurations assume the same thing: either Sysmon is the only EDR on the host (a deployment posture that exists in air-gapped, regulatory-no-cloud, or unlicensed environments) or it is augmenting an EDR whose collection surface is known. The augment case is the one where the field has converged on Hartong. To understand why, we have to look at what the other EDR -- Microsoft's own -- actually collects on the host.

6. Microsoft Defender for Endpoint: The Documented On-Host Surface

Two questions about MDE have very different answers. What does Microsoft Defender for Endpoint run on this host? has a primary-source-quality answer from Microsoft Learn. What does it actually do? has only a community-observed answer. The documented surface is the user-mode component inventory plus registry hives and event sources. The community-observed surface includes the kernel-callback inventory, the cloud TLS-pinning details, and the inter-process communication paths -- none of which Microsoft has published. Naming both halves with the right citations on each side is one of the few things this article does that other writeups skip.

The documented surface (Microsoft Learn, primary)

On every onboarded Windows endpoint, Microsoft Defender for Endpoint installs and runs a Windows service named Sense, whose display name is "Microsoft Defender for Endpoint Service" and whose backing executable is MsSense.exe. The on-host troubleshooting page documents the canonical health-check command: sc query sense [@sense-troubleshoot]. On Windows Server 2019, Server 2022, Server 2025, and Azure Stack HCI 23H2 or later, MDE is delivered as a Feature on Demand with the capability name Microsoft.Windows.Sense.Client~~~~. Microsoft documents the verification command verbatim: "DISM.EXE /Online /Get-CapabilityInfo /CapabilityName:Microsoft.Windows.Sense.Client~~~~" [@sense-troubleshoot][@ms-server-endpoints-learn].

Onboarding state is recorded under two registry hives that Microsoft Learn names explicitly:

HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection -- the policy-driven configuration surface.
HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status -- the run-time onboarding state.

Onboarding diagnostics land in the WDATPOnboarding event source under the Application event log, with documented event IDs 5, 10, 15, 30, 35, 40, 65, and 70, each of which corresponds to a specific failure mode with a specific resolution procedure [@sense-troubleshoot]. The product installs to C:\Program Files\Windows Defender Advanced Threat Protection\ (the legacy path is preserved even after the September 2020 rebrand).

The documented surface stops here. Microsoft Learn names MsSense.exe, the Sense service, the registry hives, the event source, the Feature on Demand, and the four operating systems. Microsoft Learn does not publish a kernel-callback inventory for the MDE EDR sensor.

The community-observed surface

Past the documented boundary, what is in field-published primary sources is the user-mode binary inventory and the cloud-side TLS path. Three companion binaries sit alongside MsSense.exe:

SenseCncProxy.exe is the cloud-command-and-control proxy. This is the binary that holds the TLS connection out to Defender XDR ingest, applies the certificate-pinning policy, and shuttles agent-bound commands (live-response actions, custom-detection-rule pushes, sensor-configuration updates) back down to MsSense.exe.
SenseIR.exe is the live-response and investigation actions binary. When a SOC analyst clicks Run script or Collect investigation package in the Defender XDR portal, SenseIR.exe is the process that fulfils the request on the endpoint side.
SenseNdr.exe is the network detection and response component, responsible for endpoint-side enrichment of network observations used in the DeviceNetworkEvents table.

These binaries are not enumerated on Microsoft Learn in the same way the Sense service itself is. They are documented in MDE incident-response runbooks, in third-party reverse-engineering posts, and in the file-system signature data on any onboarded endpoint. The article treats their existence as community-observed. SenseIR.exe is corroborated by InfoGuard 2025's reverse-engineering of MDE's live-response cloud path [@infoguard-2025]; SenseNdr.exe in particular lacks an explicit community primary writeup as of 2026 -- its role here is inferred from its on-disk binary metadata and the file-system signature data on onboarded endpoints.

The kernel-side surface MDE shares with Defender Antivirus is documented in the Defender Antivirus product line [@ms-defender-av-arch]:

WdBoot.sys is the Early-Launch Antimalware (ELAM) driver. It is the first non-Windows driver to load at boot and gates which non-ELAM drivers are allowed to load after it. It is signed with the Antimalware Extended Key Usage, 1.3.6.1.4.1.311.61.4.1 [@ms-learn-elam-sample].
WdFilter.sys is the Defender Antivirus file-system minifilter. It sits alongside SysmonDrv.sys at a different Filter Manager altitude.
WdNisDrv.sys is the Network Inspection System driver, which provides the host-firewall-augmenting NIS layer.

A Windows process-protection level, introduced in Vista (as Protected Process, for DRM) and extended in Windows 8.1 (for antimalware), that prevents user-mode debugger attach, code injection, and `OpenProcess` for write from any caller that does not itself run at an equal or higher PPL signer level. Antimalware-PPL (`PROTECTED_ANTIMALWARE_LIGHT`) is the level reserved for security products signed with the Antimalware EKU; `MsSense.exe` and Sysmon v15+ both run at this level. The Windows boot-order privilege that lets a driver signed with the Antimalware EKU `1.3.6.1.4.1.311.61.4.1` [@ms-learn-elam-sample] load before any non-ELAM driver and classify subsequent boot-start drivers as `Good`, `Bad`, or `Unknown` so the kernel can decide which to load. The ELAM driver *itself* is measured (along with the bootloader, kernel, and other early-boot artefacts) into TPM PCRs by Windows's *Measured Boot*, which is a separate boot-integrity feature; ELAM's job is to classify, not to measure. Defender Antivirus's `WdBoot.sys` is the canonical ELAM driver. Sysmon's `SysmonDrv.sys` is *not* ELAM-signed; this is the pre-driver-load horizon discussed in §12. The Authenticode Extended Key Usage `1.3.6.1.4.1.311.61.4.1` [@ms-learn-elam-sample], issued by Microsoft to security vendors after a code-signing and behavioral review. The EKU gates two distinct things: ELAM signing eligibility (so the driver loads first) and Antimalware-PPL eligibility for the user-mode service (so the service is harder to tamper with). MDE's `MsSense.exe`, Defender Antivirus's `MsMpEng.exe`, and Sysmon v15+ all carry this signature path.

Antimalware-PPL on MsSense.exe

The MsSense.exe service runs as Antimalware-PPL -- PROTECTED_ANTIMALWARE_LIGHT in the kernel data structure. The protection level prevents an attacker with SYSTEM privileges from attaching a user-mode debugger, suspending the service, or injecting code into its address space using ordinary Windows debugging or code-injection APIs. This is the same protection level Sysmon v15+ runs at, and it is the same level Defender Antivirus's MsMpEng.exe has run at since Windows 8.1. The structural defense closes user-mode tampering as a class. The residual attack surface is kernel-mode primitives -- which is what FalconForce had to use in 2022 to debug MDE [@falconforce-2022].

The dispositive reverse-engineering primary: FalconForce 2022

Olaf Hartong and Henri Hambartsumyan, working at FalconForce, published the most-cited reverse-engineering writeup of MDE's on-host architecture in 2022. The post's TL;DR captures both the debug-bypass technique and the cloud vulnerability that resulted from applying it:

You can debug MDE running on an endpoint by running `dbgsrv.exe` and raising its PPL protection to WinTcb. This can be used to snoop on data being transmitted by MDE to the cloud. We identified a vulnerability related to missing authorization checks of data sent from the MDE endpoint to the M365 cloud, allowing anyone to send spoofed data to any M365 tenant.

The technique is precise [@falconforce-2022]. FalconForce raised the PPL signer level of Windows's PE debug server (dbgsrv.exe) to WinTcb -- a signer level higher than Antimalware-PPL -- and used the elevated debug server to attach to MsSense.exe. From inside that debug session they instrumented SspiCli!EncryptMessage, the SSPI function MDE's cloud transport uses to wrap each outbound message before TLS encryption, and captured the plaintext payloads. The plaintext capture surfaced CVE-2022-23278: a missing-authorization vulnerability in which the M365 cloud trusted whatever device-identifying claims the endpoint asserted, with no cross-check that the asserting endpoint owned the device identity it claimed [@msrc-cve-2022-23278][@nvd-cve-2022-23278]. Microsoft patched the vulnerability on March 8, 2022, with a public acknowledgement to FalconForce: "Microsoft released a security update to address CVE-2022-23278 in Microsoft Defender for Endpoint. This important class spoofing vulnerability impacts all platforms. We wish to thank Falcon Force for the collaboration on addressing this issue through coordinated vulnerability disclosure" [@msrc-cve-2022-23278].

Note: The kernel-and-Defender-Antivirus surface MDE shares (WdBoot.sys ELAM, WdFilter.sys minifilter, WdNisDrv.sys NIS) is documented. The specific callback inventory the MDE EDR sensor itself registers is not. The community's best-published primary for what MsSense.exe actually does is the FalconForce 2022 reverse-engineering writeup -- and it covers a narrow slice (TLS interception and one cloud-authorization bug), not a full callback list. The Hartong sysmonconfig-mde-augment.xml config exists as a community-curated artifact precisely because Microsoft has not published a per-ActionType-to-per-kernel-callback cross-walk. The most-cited operational config in the field is downstream of a documentation gap. This is the second aha moment of the article.

Putting the on-host pieces together

flowchart TD B["WdBoot.sys (ELAM, Antimalware EKU)"] -.boot order.-> F["WdFilter.sys (file minifilter)"] B -.boot order.-> N["WdNisDrv.sys (Network Inspection)"] F --> M["MsSense.exe (Antimalware-PPL aggregator)"] N --> M M --> IR["SenseIR.exe (Live Response)"] M --> NDR["SenseNdr.exe (Network Detection)"] M --> P["SenseCncProxy.exe (cloud forwarder)"] P -- "TLS + certificate pinning" --> C["Defender XDR ingest (regional Kusto)"]

The picture is asymmetric: the kernel-driver substrate at the top is documented in the Defender Antivirus product line; the user-mode service inventory in the middle is documented for MsSense.exe and partly documented for the companion binaries; the cloud transport at the bottom is documented at the API-contract level (TLS, certificate pinning) but the specific endpoints and the on-the-wire payload format are reverse-engineered. The community published primaries -- FalconForce 2022 above the line, InfoGuard Labs 2025 below it -- are how the field knows what they know about the cloud-bound payload. Which is the next layer.

7. The Cloud Pipeline: SenseCncProxy.exe to Defender XDR Ingest

The wire between MsSense.exe and Microsoft's cloud is TLS with certificate pinning. It is also, twice in the last four years, the place where the most interesting Defender for Endpoint vulnerabilities have lived. The 2022 round closed one of them. The 2025 round is still open as of this article's writing.

Certificate pinning and the FalconForce 2022 method

MsSense.exe does not trust whatever the Windows certificate store says about the chain to Defender XDR ingest. It pins the certificate. FalconForce's bypass is the one §6 already named: raise dbgsrv.exe to WinTcb PPL, attach the elevated debug server to MsSense.exe, instrument SspiCli!EncryptMessage to capture the plaintext payload before TLS encryption [@falconforce-2022].The specific PPL elevation technique is published in the same writeup. PPLKiller's /enablePPL patch writes the Antimalware-PPL bit into dbgsrv.exe's _EPROCESS.Protection field at the highest signer level (WinTcb). The result: a PE debug server running at a PPL level above Antimalware-PPL, with OpenProcess rights against any Antimalware-PPL target [@falconforce-2022]. This requires SYSTEM plus a kernel primitive, typically delivered via BYOVD.

The InfoGuard Labs 2025 follow-up took a different route to the same problem. Instead of reading plaintext before TLS encryption, InfoGuard patches the certificate-chain validation function in memory so the endpoint certificate is no longer checked at all. Any local TLS-stripping proxy can then intercept the wire. The verbatim patch is two CPU instructions written into CRYPT32!CertVerifyCertificateChainPolicy: "mov eax, 1; ret" -- which forces the function to return success without performing any actual chain check [@infoguard-2025].

With the pinning gate disabled, InfoGuard's team observed the on-the-wire protocol. The cloud-bound payload goes to two endpoint families: /edr/commands/cnc for command-and-control and /senseir/v1/actions/ for live-response actions. The vulnerability they then disclosed is that both endpoint families accept "data sent from the MDE endpoint to the cloud ... without validating authentication tokens, allowing a post-breach attacker with a machine's ID to hijack the command-and-control channel" [@infoguard-2025]. Microsoft's response, verbatim: "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" [@infoguard-2025].

FalconForce 2022 found a missing-authorization bug in the cloud's trust path. CVE-2022-23278 was patched. InfoGuard Labs 2025 found a different missing-authorization pattern in different cloud endpoints -- different bug, same class -- and the disclosure record says Microsoft has not committed to a fix. The cloud trusts whatever the endpoint claims about itself far enough that the same authorization gap keeps surfacing. The arc that began with the March 2022 spoofing-CVE patch is not closed. This is the third aha moment of the article, surfaced again in §11.

What the cloud does on arrival

Once SenseCncProxy.exe has TLS-shipped the event over the wire to the regional Defender XDR ingest endpoint, two things happen on the cloud side. First, the event lands in the Advanced Hunting Kusto cluster. Microsoft Learn's verbatim freshness claim is: "Advanced hunting receives this data almost immediately after the sensors that collect them successfully transmit it to the corresponding cloud services" [@advanced-hunting-overview]. "Almost immediately" is empirically a few seconds in steady state, which is exactly what Maya saw in §1: a row with Timestamp three seconds in the past.

Second, the event is replicated for use by Microsoft's built-in detection rules, MITRE-mapped queries, and the cross-domain correlation surface that joins endpoint events to email events, identity events, and cloud-application events. The cross-domain join is one of the most-cited reasons enterprises stay on the licensed product rather than fall back to standalone Sysmon: KQL can join DeviceProcessEvents to EmailEvents to IdentityLogonEvents in one query, and Sysmon-only deployments cannot do that without a separate SIEM doing the cross-source enrichment.

Data residency is documented at the regional level in the MDE configure-server-endpoints page: "data is stored in the US for customers in the USA; in EU for European customers; and in the UK for customers in the United Kingdom" [@ms-server-endpoints-learn]. Retention in-portal is the same quota for all geographies: "Advanced hunting is a query-based threat hunting tool that you use to explore up to 30 days of raw data" [@advanced-hunting-overview]. Past 30 days, the customer has to extend the retention surface via Microsoft Sentinel's per-table archiving, which is the operational story §9 picks up.

The event's journey, end to end

sequenceDiagram participant K as Kernel callback (WdFilter or SysmonDrv) participant S as MsSense.exe (Antimalware-PPL) participant P as SenseCncProxy.exe participant CP as CRYPT32!CertVerifyCertificateChainPolicy participant C as Defender XDR ingest (regional Kusto) participant Q as DeviceProcessEvents table K->>S: Synchronous callback notification Note over S: Enrich (parent PID, hashes, identity, ProcessGuid) S->>S: SspiCli!EncryptMessage (FalconForce 2022 plaintext capture point) S->>P: IPC to cloud forwarder P->>CP: Validate Defender XDR certificate chain CP-->>P: Pinned chain OK (InfoGuard 2025 bypass: patch CP to return 0 unconditionally) P->>C: HTTPS POST /edr/commands/cnc or /senseir/v1/actions/ C->>Q: Write into Kusto cluster Note over Q: "Almost immediately" -- seconds end to end Q-->>K: Queryable via KQL

The diagram is annotated with the two community-disclosed interception points because they are the two places the field has actually been able to observe what is on the wire. Between SspiCli!EncryptMessage (where the plaintext payload exists) and CRYPT32!CertVerifyCertificateChainPolicy (where the certificate chain gets validated), the path is otherwise opaque to external researchers. The Microsoft-published side of the story is the contractual one: TLS, certificate pinning, regional ingest, Kusto cluster, KQL exposure. The reverse-engineered side fills in the rest.

Within seconds, the event appears as a row in DeviceProcessEvents. The reader-side schema is where the analyst lives. So: what columns?

8. Six `Device*` Tables and One Worked KQL Query

Every detection rule in Microsoft Defender XDR, every hunting query in Microsoft Sentinel, and every analyst pivot Maya does on her console is a KQL query against six load-bearing tables. Knowing those six tables is the price of admission to the Defender XDR field.

Microsoft's data-explorer query language, originally built for Azure Data Explorer (formerly Kusto). KQL reads as a pipeline of operators -- `where`, `project`, `summarize`, `join`, `order by` -- left to right. Advanced Hunting in Microsoft Defender XDR and analytics queries in Microsoft Sentinel both expose the same KQL dialect; the same query text can be moved between the two surfaces with only the table-name namespace changing [@advanced-hunting-overview][@sentinel-xdr-connector].

The six tables

The six tables that this article calls "load-bearing" are the ones that map most cleanly to Sysmon's manifest and that detection rules join against most often:

DeviceProcessEvents -- the canonical reader-side analogue of Sysmon's EID 1 (ProcessCreate) and EID 5 (ProcessTerminate). The schema reference page names roughly fifty columns including Timestamp, DeviceId, DeviceName, ActionType, FileName, FolderPath, SHA1, SHA256, MD5, FileSize, ProcessId, ProcessCommandLine, ProcessIntegrityLevel, ProcessTokenElevation, ProcessCreationTime, AccountSid, AccountName, AccountUpn, LogonId, and the full InitiatingProcess* family of parent-process columns [@deviceprocessevents-table].
DeviceNetworkEvents -- the analogue of Sysmon EID 3 (NetworkConnect) plus EID 22 (DNSEvent) and the MDE-only network-protection telemetry. Columns include RemoteIP, RemotePort, RemoteUrl, LocalIP, LocalPort, Protocol, RemoteIPType, and the InitiatingProcess* family [@sentinel-xdr-connector].
DeviceFileEvents -- the analogue of Sysmon EIDs 11 (FileCreate), 15 (FileCreateStreamHash), 23 (FileDelete archived), and 26 (FileDeleteDetected).
DeviceImageLoadEvents -- the analogue of Sysmon EID 7 (ImageLoad).
DeviceRegistryEvents -- the analogue of Sysmon EIDs 12-14 (RegistryEvent family).
DeviceEvents -- the miscellaneous catch-all. AMSI scan results, exploit-protection events, ASR rule fires, Network Protection blocks, and other MDE-specific events that do not fit cleanly into any of the per-event-class tables surface here as ActionType discriminators.

Past the six core tables there are siblings the article does not walk in detail but that detection engineers query alongside: DeviceLogonEvents (interactive, remote-interactive, network logons), DeviceFileCertificateInfo (Authenticode signer information), DeviceInfo and DeviceNetworkInfo (asset and posture). The cross-domain tables that the Defender XDR portal exposes -- AlertInfo, AlertEvidence, IdentityLogonEvents, EmailEvents, CloudAppEvents -- are also queryable from the same surface, and the cross-domain join is one of the load-bearing reasons SOC teams move queries from a standalone SIEM into Advanced Hunting [@sentinel-xdr-connector].

Sysmon EID to MDE table cross-walk

The cross-walk is the table detection engineers actually need at their desk. Every row is a Sysmon EID, the MDE table the analogous event lands in, the ActionType discriminator inside that table, and a fidelity rating relative to Sysmon's manifest -- because the MDE schema does not surface every Sysmon field, and the fidelity gaps are where Hartong's MDE-augment config earns its keep.

Sysmon EID	MDE table	ActionType	Fidelity vs Sysmon	Hartong-augment disposition
1 ProcessCreate	DeviceProcessEvents	ProcessCreated	Full	Drop (MDE covers)
3 NetworkConnect	DeviceNetworkEvents	ConnectionSuccess	Full	Drop
7 ImageLoad	DeviceImageLoadEvents	ImageLoaded	Full	Drop
8 CreateRemoteThread	DeviceEvents	RemoteThreadCreated	Truncated (no SourceImage hash)	Keep verbose
9 RawAccessRead	(none)	--	Omitted	Keep
10 ProcessAccess	DeviceEvents	OpenProcessApiCall	Truncated (no GrantedAccess mask)	Keep verbose, narrow targets
11 FileCreate	DeviceFileEvents	FileCreated	Full	Drop
12-14 RegistryEvent	DeviceRegistryEvents	RegistryValueSet etc.	Full	Drop
17-18 PipeEvent	(none)	--	Omitted	Keep
19-21 WmiEvent	(none)	--	Omitted	Keep
22 DNSEvent	DeviceNetworkEvents	DnsQuery	Full	Drop
23 FileDelete (archive)	DeviceFileEvents	FileDeleted	Partial (no archive)	Keep archive variant on selected paths
26 FileDeleteDetected	DeviceFileEvents	FileDeleted	Full	Drop
27 FileBlockExecutable	(none)	--	Omitted (MDE has separate prevent surface)	Keep if Sysmon is enforcing

The fidelity column is the operational answer to "do I need Sysmon if I have MDE?" Where MDE is Full, Sysmon duplicates. Where MDE is Truncated, Sysmon adds the fields MDE drops. Where MDE is Omitted, Sysmon is the only collection mechanism in the host's telemetry surface. This is the cross-walk that Hartong's sysmonconfig-mde-augment.xml implements as XML rules.

The Kusto Hunt: PowerShell instances that called out within sixty seconds of spawn

The single most-frequently-cited hunting query in the Defender XDR field is some variation of the following. The query joins DeviceProcessEvents to DeviceNetworkEvents on (DeviceId, InitiatingProcessId) and surfaces every PowerShell instance that opened an outbound network connection within sixty seconds of being spawned. This is the query that turns Maya's hunch ("that base64-encoded command looks bad") into a SIEM-routable signal:

// The Kusto Hunt: PowerShell instances that called out within
// 60s of process create, joined on (DeviceId, InitiatingProcessId).
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "powershell.exe" or FileName =~ "pwsh.exe"
| project DeviceId, ProcessId, ProcessCreationTime = Timestamp,
          ParentImage = InitiatingProcessFileName,
          ParentCmd   = InitiatingProcessCommandLine,
          ProcessCmd  = ProcessCommandLine,
          User        = AccountUpn
| join kind=inner (
    DeviceNetworkEvents
    | where Timestamp > ago(24h)
    | where ActionType == "ConnectionSuccess"
    | project DeviceId, InitiatingProcessId, NetTime = Timestamp,
              RemoteIP, RemotePort, RemoteUrl
) on DeviceId, $left.ProcessId == $right.InitiatingProcessId
| where (NetTime - ProcessCreationTime) between (0s .. 60s)
| where RemoteIP !startswith "10."
    and RemoteIP !startswith "192.168."
    and not(RemoteIP matches regex "^172\\.(1[6-9]|2[0-9]|3[0-1])\\.")
| project DeviceId, ProcessCreationTime, NetTime,
          ParentImage, ProcessCmd, RemoteIP, RemotePort, RemoteUrl, User
| order by NetTime desc

The query is twelve operative lines and exercises four of KQL's most useful primitives: join (on a tuple key), between (for time-window matching), !startswith and the regex check (for RFC 1918 exclusion), and project (for column shaping). The between (0s .. 60s) is the crux. A legitimate PowerShell launched by a logon script may also produce a network connection within the same minute -- the filter is necessary but not sufficient. Adding ParentImage in ("winword.exe", "excel.exe", "outlook.exe") narrows the hunt to the Office-spawning-PowerShell pattern that fits the Emotet and Qbot families. Adding RemoteUrl in (~CustomTI) narrows the hunt further to known-bad indicators from the tenant's threat-intelligence list.

{` // JavaScript that walks through the logic of the KQL hunt. // The actual query runs in Advanced Hunting; this runs in your browser // so you can see the join semantics with a small synthetic dataset.

const processEvents = [ { DeviceId: "D1", ProcessId: 7700, Timestamp: 100, FileName: "powershell.exe", InitiatingProcessFileName: "WINWORD.EXE", ProcessCommandLine: "powershell.exe -enc JABzAD0A..." }, { DeviceId: "D2", ProcessId: 4422, Timestamp: 200, FileName: "powershell.exe", InitiatingProcessFileName: "explorer.exe", ProcessCommandLine: "powershell.exe -Help" }, ];

const networkEvents = [ { DeviceId: "D1", InitiatingProcessId: 7700, Timestamp: 130, ActionType: "ConnectionSuccess", RemoteIP: "185.243.115.84", RemotePort: 443 }, { DeviceId: "D2", InitiatingProcessId: 4422, Timestamp: 215, ActionType: "ConnectionSuccess", RemoteIP: "10.0.0.5", RemotePort: 443 }, ];

function isPrivate(ip) { return ip.startsWith("10.") || ip.startsWith("192.168.") || /^172\.(1[6-9]|2[0-9]|3[0-1])\./.test(ip); }

console.log(JSON.stringify(hits, null, 2)); // Expected output: one hit on D1 (WINWORD-spawned powershell to public IP); // D2 is filtered out (RemoteIP is RFC 1918 private). `}

The semantic of the KQL is the semantic of the JavaScript: a relational join on a composite key, filtered by a time-window predicate and a network-class predicate. The KQL query is shorter and faster; the JavaScript is what the join is actually doing. Once a reader internalizes this pattern, the rest of the Advanced Hunting surface unfolds from it -- every other detection in the field is a variant of "join Device* table A to Device* table B on (DeviceId, InitiatingProcessId), filter by time and content."Advanced Hunting per-query quotas are 100,000 rows of returned data and 10 minutes of execution time per call [@advanced-hunting-overview]. The practical workaround for queries that exceed either limit is to pre-filter with a tighter time window (Timestamp > ago(1h) instead of ago(24h)), or to push the heavy aggregation into a Sentinel scheduled analytics rule that runs every hour and materializes the result table for further hunting.

The same query, the same columns, the same six tables surface in two different places: the Defender XDR portal itself (at security.microsoft.com legacy or defender.microsoft.com current), and inside Microsoft Sentinel via the Defender XDR connector. The two surfaces are not the same.

9. The Microsoft Sentinel Integration Model

The same KQL query runs in two different places, but the economics of the two places are not the same, and that distinction is the one that catches detection engineers off guard. In-portal Advanced Hunting and Microsoft Sentinel both expose the same Device* tables. They do not expose them with the same retention, the same join surface, or the same cost.

The connector contract

Microsoft Sentinel's Defender XDR connector (the post-Ignite-2023 successor to the legacy Microsoft 365 Defender connector) streams Microsoft Defender XDR incidents, alerts, and Advanced Hunting events into Sentinel's Log Analytics workspace. Microsoft Learn's verbatim definition is: "The Defender XDR connector allows you to stream all Microsoft Defender XDR incidents, alerts, and advanced hunting events into Microsoft Sentinel and keeps incidents synchronized between both portals" [@sentinel-xdr-connector]. The connector exposes per-table streaming, meaning the operator picks which Device* tables to bring into Sentinel and pays per-GB ingestion only on those tables.

The connector also handles the legacy-connector transition: when enabled, "any Microsoft Defender components' connectors that were previously connected are automatically disconnected in the background" [@sentinel-xdr-connector]. If a tenant was using the legacy Microsoft Defender ATP connector or per-product Defender connectors, those get retired when the unified Defender XDR connector takes over. This is the cleanup detail that catches teams off guard during the migration -- they expect both connectors to coexist for the transition window, and they do not.

Three asymmetries

The in-portal Advanced Hunting surface and the Sentinel surface differ on three practitioner-level axes:

Dimension	In-portal Advanced Hunting	Sentinel + Defender XDR connector
Retention	30 days of raw data per query [@advanced-hunting-overview]	Configurable per-workspace, up to 12 years archive [@sentinel-xdr-connector][@ms-log-analytics-archive]
Query surface	Six core `Device*` tables plus cross-domain `AlertInfo` / `EmailEvents` / `IdentityLogonEvents` / `CloudAppEvents`	Six core `Device*` tables (per-table selection) plus the entire Log Analytics workspace -- third-party logs, custom tables, ASIM-normalized data
Cost	Included with MDE Plan 2 license	Per-GB Sentinel ingestion (current GA tier) plus per-GB archive
Detection authoring	Custom detection rules; in-portal advanced-hunting-to-alert promotion	Scheduled analytics rules; SOAR playbook triggers; automation rules
Cross-tenant hunting	Tenant-bound only	Possible via Lighthouse / Sentinel Workspaces aggregation
Live response triggers	In-portal action surface	Via Logic Apps / Defender API connector

The in-portal economics are predictable: the queries are included with the license, the retention is uniform at thirty days, the surface is the six tables plus the cross-domain entity catalogue. The Sentinel economics are flexible but billable: longer retention, more table coverage, more automation, all of which carry per-GB ingestion charges. The choice is operational: which queries does the team need to run on data older than thirty days?

When each surface is the right one

For the SOC-analyst-driven, real-time threat-hunting workflow that §1 modeled with Maya -- thirty days back, six tables, cross-domain join into AlertInfo -- the in-portal Advanced Hunting surface is the obvious fit. For the longer-retention, multi-source, automated-analytic-rule workflow -- where detection engineers want a scheduled rule that joins DeviceProcessEvents to a third-party identity log on a normalized schema -- the Sentinel surface is the obvious fit.

The two surfaces are not exclusive. The most-cited operational pattern in 2026 is to keep the in-portal surface as the SOC-analyst hunting console (retention 30 days, no cost) and to run the Defender XDR connector into Sentinel for the subset of tables the team needs longer retention or analytics-rule scheduling on. Per-table selection keeps the per-GB ingestion bill predictable.The Sentinel connector preserves table names but namespaces them inside the Log Analytics workspace; DeviceProcessEvents in Sentinel is the same shape as DeviceProcessEvents in the Defender XDR portal, and most queries port between the two surfaces unchanged. Some columns are renamed at the connector boundary -- the most common gotcha is the time-zone and timestamp representation -- but the join semantics and the cross-walk to Sysmon EIDs do not change.

The portal-URL transition

A small operational detail worth naming: the Defender XDR portal lives at both security.microsoft.com (legacy, still functional) and defender.microsoft.com (current). The new URL was announced as part of the Microsoft 365 Defender to Microsoft Defender XDR rebrand at Ignite 2023 [@defender-xdr-ms-learn][@ms-ignite-2023-blog]. The rebrand changed neither the KQL substrate nor the Device* schema; queries written against the legacy URL behave identically against the new URL. This is the disambiguation §1 alluded to in its layer-7 description: the same KQL query, the same tables, against either URL.

Two query surfaces, six tables, twenty-nine Sysmon EIDs, and one operational question every SOC manager has asked at least once: do we deploy Sysmon alongside Defender for Endpoint, or trust Defender alone? That is §10.

10. Sysmon Plus MDE: Three Coexistence Patterns

This is the operational question of the article. The community has converged on three answers, and one of them is wrong for almost every MDE-licensed environment. The three options, in order of increasing complexity and -- in most enterprise contexts -- decreasing prevalence:

Option A: Sysmon only, no MDE

Used in air-gapped environments, unlicensed environments, and regulatory contexts that prohibit cloud-side telemetry. Sysmon on its own produces a complete event stream into the local Windows event log, which a downstream collector (Windows Event Forwarding to a central collector, Splunk's Universal Forwarder, Wazuh's Windows agent, the Elastic Endpoint integration) picks up and ships to a customer-controlled SIEM. The trade-off: no cross-tenant correlation, no cloud-side threat-intelligence join, no EtwTi (kernel security ETW provider) consumption, no Microsoft-authored detection rules. The customer owns every rule themselves.

This is the right answer in a small set of contexts and the wrong answer in the licensed-enterprise context where MDE is already deployed.

Option B: MDE only, no Sysmon

The Microsoft-recommended baseline for licensed environments. MDE's Device* schema covers the high-value Sysmon EID surface -- 1, 3, 7, 10, 11, 12-14 -- at full or near-full fidelity, and MDE adds the layers Sysmon does not have: cloud-side correlation, cross-domain joins (email, identity, cloud apps), Microsoft-authored built-in detection rules with continuous tuning, the AlertInfo/AlertEvidence evidence graph, and the SOC-actionable surface (device isolation, live response, automated investigation) [@mde-ms-learn][@ms-mitre-2024-blog].

For most MDE-Plan-2-licensed organizations without a mature detection-engineering team, Option B is the right baseline. The trade-off is that the truncations and omissions in the Device* schema -- the ProcessAccess GrantedAccess mask Sysmon EID 10 surfaces verbatim that MDE drops, the WMI consumer expressions Sysmon EIDs 19-21 capture that MDE does not surface, the RawAccessRead and PipeEvent classes Sysmon captures that MDE omits entirely -- are not available to the team's custom hunting queries. For an organization without the engineering capacity to build hunting rules on those verbose surfaces, this is rarely a binding constraint.

Option C: MDE plus tuned Sysmon (Hartong's MDE-augment)

The detection-engineering-community pattern. Run MDE as the primary EDR. Run Sysmon alongside it with olafhartong/sysmon-modular's sysmonconfig-mde-augment.xml configuration, whose explicit README design intent is "intended to augment the information and have as little overlap as possible" with MDE [@github-hartong-modular]. The augment config drops the EIDs MDE covers cleanly (1, 3, 7, 11, 12-14, 22) and keeps the EIDs MDE truncates or omits (8 with full SourceImage, 9 RawAccessRead, 10 with full GrantedAccess mask, 15 FileCreateStreamHash, 17-18 PipeEvent, 19-21 WmiEvent, 23 with archive variant on narrowly-scoped paths). The result is a Sysmon event-log stream that is purpose-built to complement MDE's Kusto stream, not duplicate it.

Key idea: If you are an MDE-licensed shop with a detection-engineering team and you are not running Hartong's sysmonconfig-mde-augment.xml, you are paying for two EDRs and getting the coverage of one. The augment config was purpose-built to make Sysmon's verbose-field surface complementary to MDE's cloud-correlation surface, not a duplicate. Standalone Sysmon next to MDE without the augment-specific exclusions is the worst of both worlds: double telemetry volume, double licensing exposure, and no incremental detection coverage.

Cost and operational complexity

The three options have different operational profiles. The summary table:

Pattern	License posture	Telemetry volume	Operational complexity	Best used for
A. Sysmon only	None (free)	Medium (depends on config)	Low (one product, one config)	Air-gapped, regulatory-no-cloud, unlicensed
B. MDE only	MDE Plan 1 or Plan 2	Cloud-controlled (no per-host volume bill)	Low (one product, Microsoft-managed)	Most MDE-licensed orgs without detection-engineering team
C. MDE + Hartong augment	MDE Plan 2 + WEF or SIEM	High on Sysmon side (verbose EIDs); low on MDE side	High (two products, modular config, WEF or SIEM forwarder)	Detection-engineering-mature SOCs

A small operational caution: standalone Sysmon next to MDE without the augment-specific exclusions is the worst of three worlds. The drivers coexist fine at different Filter Manager altitudes, but the event log and downstream collector now carry every Sysmon EID the default config emits plus everything MDE collects on the cloud side. The double-pay problem the KeyIdea calls out is not theoretical; it shows up the first month a SOC team forgets to swap the default sysmonconfig.xml for sysmonconfig-mde-augment.xml.

The Hartong-augment-with-MDE pattern carries a second cost: the ETW manifest-provider session cap. Windows allows up to eight trace sessions to enable and receive events from the same manifest-based provider [@ms-etw-limits]; the EtwTi security provider, Microsoft Defender Antivirus auto-start sessions, and any WPR sessions a developer might spin up all compete for that shared pool. Adding Sysmon's session takes one. On a host with a third-party EDR that already consumes several sessions against the same provider, this can cause silent telemetry loss. Audit logman query -ets regularly.

The volume math

For sizing, assume a typical Windows endpoint generates roughly 20,000 process-create events per day under steady state (developer workstations are in this range; server volumes are higher; air-gapped jump boxes are lower) [@github-tsale-edr-telem]. The Hartong-augment config drops the top three high-volume EIDs (1 ProcessCreate, 7 ImageLoad, 11 FileCreate) that MDE already collects, retaining only the verbose surfaces. That cuts Sysmon volume by roughly 70 to 85 percent relative to a default-config Sysmon deployment, leaving only the verbose-EID stream (8, 10, 17-18, 19-21) MDE does not surface.

This is the operational answer to the question. For organisations with detection-engineering teams, Option C is the default. For organisations without, Option B is the default. Option A is correct in a narrow set of contexts and should be picked on purpose. The next two sections turn from the layered architecture to the layered attack surface, because every defense has an attacker.

11. The Attack Tradition: Telemetry Suppression on Both Halves of the Pipeline

If you run an EDR on a host, you have made a bet that the EDR can survive contact with an attacker who knows it is there. The history of that bet -- on both halves of the pipeline -- is a chronological story with named techniques and named CVEs. Twelve years of attack tradition reduce to a small number of attack classes plus the structural defenses that closed each one.

Sysmon-side attacks, in order

The earliest tampering technique for Sysmon was the most obvious: stop the driver. Until Sysmon v15 in June 2023, the Sysmon service was a normal Windows service, and a SYSTEM-privilege attacker had several easy options:

sc stop sysmon and sc delete sysmon to unload SysmonDrv.sys.
Rewrite the minifilter altitude so Sysmon loads after a tamper hook.
wevtutil cl Microsoft-Windows-Sysmon/Operational to erase history.
Rewrite SYSTEM\CurrentControlSet\Services\SysmonDrv\Parameters to re-program Sysmon's filter without restarting it.
Register a Windows event-channel ACL change to silence Microsoft-Windows-Sysmon.

A small family of community-published tools automated this class. The structural defense, before v15, was discipline: keep SYSTEM out of attacker hands.

The June 2023 v15 protected-process gate is the structural response to this entire class. Microsoft Learn states the change verbatim: "The service runs as a protected process, thus disallowing a wide range of user mode interactions" [@sysmon-ms-learn]. A SYSTEM-privilege attacker can no longer OpenProcess(PROCESS_TERMINATE) against Sysmon.exe, inject code into the service's address space, or attach a user-mode debugger. The class is not closed -- a kernel primitive still works, and a BYOVD chain that can write _EPROCESS.Protection defeats the gate -- but the bar moves from "a wevtutil command in a PowerShell window" to "a kernel exploit primitive."

MDE-side attacks, in order

The MDE-side attack tradition starts at the Antimalware-PPL boundary on MsSense.exe. The FalconForce 2022 work this article has already cited multiple times is the dispositive primary [@falconforce-2022]. The verbatim TL;DR -- describing how raising dbgsrv.exe to WinTcb PPL lets researchers debug MDE and capture cloud-bound payloads, which surfaced a missing-authorization vulnerability allowing spoofed telemetry to any M365 tenant -- landed earlier as the §6 PullQuote and is the framing this section builds on.

The technique used a PPLKiller-class BYOVD chain to raise dbgsrv.exe to WinTcb PPL, attach to MsSense.exe, and capture plaintext payloads via SspiCli!EncryptMessage instrumentation. The vulnerability that work disclosed, CVE-2022-23278, was patched on March 8, 2022 [@msrc-cve-2022-23278][@nvd-cve-2022-23278]. That patch closed one missing-authorization gap in the cloud-side trust model. It did not close the class.

The InfoGuard Labs 2025 follow-up [@infoguard-2025] demonstrated that the broader class is still open. The technique they used was different -- in-memory patching of CRYPT32!CertVerifyCertificateChainPolicy to disable certificate-pinning validation, rather than PPL-elevated debugging -- but the vulnerability they surfaced is the same class: cloud endpoints (/edr/commands/cnc and /senseir/v1/actions/) that do not properly validate authentication tokens on traffic claiming to originate from the endpoint. As §7 documented, the MSRC disposition was low severity, no fix committed -- the operational consequence is that the spoofed-telemetry trust pattern that produced CVE-2022-23278 in 2022 is, three years later, still exploitable along a parallel surface.

The broader attack class -- ETW Threat Intelligence (EtwTi) blinding -- has been studied independently of MDE. The structural answer in 2026 is HVCI plus VBL plus Antimalware-PPL plus ELAM (the four-component hardening stack). On a fully-hardened endpoint, the user-mode tamper surface that defined the 2014-to-2020 era of EDR-blinding tradecraft is largely closed; the residual attack surface is kernel-mode adversary primitives. That is the structural ceiling §12 picks up.

Cross-pipeline attacks

Some attacks affect both halves of the pipeline simultaneously. The most-cited is BYOVD-driven kernel-callback removal: a Bring-Your-Own-Vulnerable-Driver chain loads a Microsoft-signed but vulnerable driver, exploits a known CVE in the driver, and from kernel context calls PsSetCreateProcessNotifyRoutineEx with a Remove = TRUE flag against the EDR sensor's registered callbacks, effectively unhooking both Sysmon and MDE at the kernel-callback layer. The structural defense Microsoft shipped in response is the Microsoft Vulnerable Driver Blocklist with HVCI enforcement, which has been on by default since Windows 11 22H2 [@ms-driver-blocklist].

A second cross-pipeline attack is direct-syscall bypass of user-mode hook libraries -- but this attack is mostly a relic from the 2010s when EDR vendors relied on ntdll.dll user-mode IAT hooks; modern Sysmon and MDE neither register nor depend on user-mode hooks for the kernel-callback events. Direct-syscall malware that bypasses the user-mode hooks of a third-party EDR will still produce a Sysmon EID 1 and an MDE DeviceProcessEvents row, because the kernel-callback fires whether or not the malware called NtCreateUserProcess via ntdll.dll.

The attack-surface lattice

flowchart TD A1["Sysmon-side: sc stop, wevtutil clear, registry altitude swap"] --> D1[Sysmon v15 protected-process gate] A2["MDE-side: PPLKiller + dbgsrv WinTcb to attach MsSense"] --> D2["Antimalware-PPL on MsSense.exe"] A3["Cloud-side: CVE-2022-23278 spoofed cloud telemetry"] --> D3["MSRC patch March 8 2022"] A4["Cloud-side: InfoGuard 2025 cert-pinning bypass + missing auth"] --> O4["OPEN: 'low severity, no fix committed'"] A5["Cross-pipeline: BYOVD kernel-callback unhook"] --> D5["HVCI + Vulnerable Driver Blocklist (Win11 22H2+)"] D1 --> R["Residual: kernel-mode adversary primitive that defeats HVCI + VBL"] D2 --> R D5 --> R D3 --> R O4 -.unclosed.-> R

The shape of the lattice is the shape of the field's hardening: every user-mode attack class has a structural defense, and the structural defenses converge on a single residual -- the kernel-mode adversary primitive that defeats HVCI plus the Vulnerable Driver Blocklist. On the cloud side, the InfoGuard 2025 finding is the unresolved item -- the same trust pattern that produced CVE-2022-23278 in 2022 produced a different cluster of missing-authorization bugs three years later. The attack-defense arc is still moving, and the two-sided nature of the pipeline (host + cloud) is why.

Every attack surface has a structural defense. But every defense has a horizon. What is outside the horizon?

12. Theoretical Limits: What the Pipeline Cannot See

Sysmon and Microsoft Defender for Endpoint are observation pipelines, not enforcement layers. That statement contains four structural ceilings the engineering cannot lift. These are not bugs to be fixed; they are properties of the architecture that follow from the choice of where the pipeline collects.

Ceiling 1: The pre-driver-load horizon

Both Sysmon's SysmonDrv.sys and Defender for Endpoint's WdBoot.sys are kernel drivers, but they sit at different points in the boot order. WdBoot.sys is ELAM-signed and loads before any non-ELAM driver, which lets it classify subsequent boot-start drivers as Good, Bad, or Unknown for the kernel's load decision. (Measured Boot separately hashes WdBoot.sys along with the bootloader and kernel into TPM PCRs; that integrity-attestation channel is a sibling feature, not ELAM's own job.) SysmonDrv.sys is BootStart-ordered but not ELAM-signed -- it loads early, but not first.

Events that happen before the EDR driver's DriverEntry runs are not observable by that driver. For Sysmon, that means rootkit-class malware that loads inside the early Windows boot path (UEFI bootkits, boot-record manipulation, very-early kernel modifications) is invisible until after Sysmon catches up. For MDE, the ELAM-signed WdBoot.sys closes most of this window for non-ELAM drivers; the residual is anything that runs even earlier -- UEFI-firmware-resident malware, hardware-implant attacks, the very narrow class that targets the pre-ELAM trust boundary itself. The Measured Boot plus Secure Boot stack (covered in adjacent articles in this series) is what observes the pre-ELAM region. EDR's reach does not extend below the ELAM line.

Ceiling 2: The observation-vs-enforcement latency gap

Sysmon's kernel-callback to event-log latency is sub-millisecond. The driver runs the rule engine, decides to emit, and writes through the ETW publisher to the Sysmon service. The service writes to the event log. The total path is microseconds in the best case, milliseconds under load.

MDE's end-to-end latency to a queryable Kusto row is seconds to tens of seconds. The endpoint side takes microseconds; the TLS hop to regional ingest takes the dominant fraction of a second; the Kusto write and per-tenant indexing takes the rest. Microsoft's own Advanced Hunting documentation phrases the freshness contract carefully: "Advanced hunting receives this data almost immediately after the sensors that collect them successfully transmit it to the corresponding cloud services" [@advanced-hunting-overview]. "Almost immediately" is empirically a few seconds in steady state, longer under load, and indefinite when the endpoint cannot reach the cloud.

Any payload that completes its work inside the observation window has executed before the SIEM rule could fire. A mimikatz.exe invocation that dumps LSA secrets in three milliseconds, exfiltrates them over a covert DNS channel in 800 milliseconds, and exits in another two milliseconds has produced a complete attack chain before MDE's event has reached Kusto, let alone before the Maya-class analyst has glanced at her console. The hybrid responses that blur this boundary -- Sysmon v14's FileBlockExecutable (EID 27), MDE's ASR rules and Network Protection -- are kernel-callback-time decisions, not SIEM-rule-time decisions; they run inside the few-microsecond window the driver itself owns, and they are constrained by the rule logic baked into the host configuration rather than by the live correlation logic of the cloud-side detection engine.

Ceiling 3: MDE schema truncation versus Sysmon manifest

This is the ceiling §8 quantified column-by-column. The Device* tables surface a normalized, mostly-complete cross-walk of Sysmon's manifest -- but mostly-complete is not the same as complete. The ProcessAccess GrantedAccess mask is the most-cited example: Sysmon EID 10 captures the full 32-bit PROCESS_ACCESS_MASK (which discriminates between PROCESS_QUERY_INFORMATION, PROCESS_VM_READ, PROCESS_CREATE_THREAD, and so on -- the canonical malicious patterns are visible in this mask), while MDE's DeviceEvents OpenProcessApiCall ActionType collapses the mask into a coarser categorization. The WmiEvent consumer expressions Sysmon EIDs 19-21 capture verbatim -- which are how WMI-based persistence is detected -- are not surfaced in the Device* schema at all. RawAccessRead (EID 9, the canonical disk-level credential-theft observable) is omitted. PipeEvent (EIDs 17-18) is omitted.

Hartong's sysmonconfig-mde-augment.xml exists precisely because of this asymmetry. The augment config is a community-curated artifact whose purpose is to fill the schema-truncation gap. The cost: a second telemetry stream on the host. The benefit: detection-engineering visibility into the verbose-EID surface MDE drops.

Ceiling 4: The kernel-mode adversary primitive

A ring-0 attacker with a working kernel primitive -- a memory-write capability into the kernel data structures, typically delivered via BYOVD against a vulnerable signed driver -- can defeat the pipeline as a consequence of defeating the structural defenses that protect it. Specifically:

Direct call to PsSetCreateProcessNotifyRoutineEx with Remove = TRUE unregisters the EDR sensor's callback, after which CreateProcess events on that host produce no observable.
A patch to the _EPROCESS.Protection field of MsSense.exe or Sysmon.exe strips the Antimalware-PPL gate, after which user-mode attacks against the service work again.
A direct write into the EtwTi provider's keyword mask zero-pages the security-event-emission surface, after which the kernel-side EtwTi consumer (which several EDRs subscribe to) sees no events even when the underlying behaviour fired.

The "Tampering with Windows Event Tracing" research published by Palantir in 2018 (Matt Graeber's canonical writeup) and the follow-on EtwTi-blinding tradition is the published primary for this attack class [@palantir-etw-tampering-2018]. The structural defenses are HVCI plus VBL plus Antimalware-PPL plus ELAM. But the four-component hardening stack does not prevent a kernel-mode adversary primitive from defeating the EDR; it only raises the bar to needing a kernel-mode adversary primitive.

Observation requires execution overhead, and execution requires the observer to live in the same trust domain as the observed. A kernel-mode observer (Sysmon, MDE) lives in the same kernel trust domain as the kernel-mode attacker; a hypervisor-rooted observer (`EtwTi` running under Virtualization-Based Security) shifts the trust boundary up one level, but does not eliminate it -- the observer-in-VBS is still subject to attacks on the hypervisor itself. There is no architectural place to put the observer that is strictly outside the attacker's reach unless the observer is in different hardware, which is what hardware-rooted Root-of-Trust attestations attempt and what an Anti-Tamper Service Provider (ATSP) is being defined for. EDR sensors will always be co-resident with the adversary at *some* trust boundary. The ceiling is structural.

Four ceilings, four sets of open questions. What is the field working on right now?

13. Open Problems and Active Work

Some questions in this article have no answer in 2026. Five of them are where the field will move next.

The MDE kernel-callback inventory

As §6's aha-moment Callout established, Microsoft has not published a kernel-callback inventory for the MDE EDR sensor, which is the structural reason Hartong's sysmonconfig-mde-augment.xml exists as a community-curated artifact rather than a Microsoft-published reference. What §13 adds is the empirical scaffolding the community uses in the absence of that inventory: the MITRE Engenuity Round 6 (2024) evaluation results [@ms-mitre-2024-blog] plus the Shen et al. whole-graph re-analysis [@arxiv-shen-2024] are the closest published evidence of which MDE detection paths produced an alert during a known emulated technique. Neither covers an end-to-end kernel-callback enumeration comparable to Sysmon's manifest -- they cover outputs (alerts produced) rather than mechanisms (callbacks registered). Closing this gap would require either Microsoft to publish a per-ActionType-to-per-kernel-callback cross-walk for the Device* schema, or the community to fund and publish a reverse-engineered inventory that goes meaningfully past the FalconForce 2022 and InfoGuard 2025 slices. As of 2026, neither has happened.

Defender XDR built-in detection rule logic

The AlertInfo and AlertEvidence table schemas are published; the underlying rule logic that produces alerts in these tables is not. Microsoft ships "Microsoft-authored detection rules" as part of Defender XDR Plan 2, and the rules update continuously without an obvious public changelog. The community workaround is to subscribe to the MITRE ATT&CK evaluation rounds (the most recent being Round 6 in 2024 [@ms-mitre-2024-blog][@arxiv-shen-2024]) and infer rule coverage from per-technique detection scores, but this is indirect and lossy. A published rule-logic catalogue would let detection-engineering teams reason about which custom rules are duplicates of Microsoft's authored content and which fill genuine gaps.

Cross-tenant hunting and data sovereignty

MSSPs (managed-security service providers) routinely need to hunt across multiple customer tenants for shared-IOC observations. Microsoft's official multi-tenant story is Microsoft Defender XDR Multitenant Management (in GA) plus Azure Lighthouse for cross-tenant Sentinel access. Both are functional and both are documented at the operational level. The deeper question -- what is the GDPR/HIPAA/FedRAMP framework around hunting an IOC observed in Tenant A against telemetry held in Tenant B's regional Kusto cluster? -- is unsettled. The data-residency commitments Microsoft makes per region [@ms-server-endpoints-learn] do not directly answer the cross-tenant-hunt question. Vendor and customer guidance is still maturing.

A Microsoft-published reference MDE-augmentation Sysmon config

Hartong's config is the community answer to the question "what Sysmon EIDs should I emit on a host that already has MDE?" There is no Microsoft-published reference equivalent. This is the most surgical near-term improvement Microsoft could make. Publishing such a config -- even as a starting-point template, not a binding recommendation -- would compress an entire detection-engineering conversation into a single endorsed artifact. The political reason it has not happened is partly that Microsoft does not officially recommend running Sysmon alongside MDE; the operational reality is that detection-engineering-mature shops do anyway.

Cross-platform parity

Sysmon for Linux (microsoft/SysmonForLinux, created October 28, 2020 and publicly announced in October 2021) ships an eBPF-based implementation of the same XML schema and emits to syslog [@github-sysmon-linux]. It is a substantial subset of the Windows manifest -- process create, file write, network connect, image load, raw access read -- with the cross-OS shared XML rule grammar going for it, so a detection-engineering team can write one Sigma-aligned rule and run it against both Windows and Linux endpoints with minor token substitutions. Full parity between the Windows kernel-callback Sysmon and the Linux eBPF Sysmon is not the design intent; the Linux port intentionally captures only the EIDs that map cleanly onto eBPF observables. BTFHub plus SysinternalsEBPF (the in-tree CO-RE infrastructure the Linux port uses) make per-kernel-version deployments tractable, but the field has not yet converged on a single canonical Linux config the way it converged on SwiftOnSecurity for Windows.

These five open problems are where the field will move in the next five years. In the meantime, what does the analyst do on Monday morning?

14. Seven Things to Do Monday Morning

Everything above has been background. Here is the operational checklist. Each step is anchored to a primary citation. Walk all seven on a single non-production host before fleet rollout; the ninety-second triage walk from §1 is best learned by reproducing it once on your own tenant.

1. Verify the MDE sensor service is healthy

Run as Administrator on the endpoint:

sc query sense

A healthy result shows STATE: 4 RUNNING and WIN32_EXIT_CODE: 0. If the result is STATE: 1 STOPPED or the service is missing entirely, consult the WDATPOnboarding event source in the Application event log for events 5, 10, 15, 30, 35, 40, 65, and 70 -- each has a documented resolution procedure [@sense-troubleshoot]. On Windows Server 2019, 2022, 2025, or Azure Stack HCI 23H2 or later, also verify the Feature on Demand is installed:

DISM.EXE /Online /Get-CapabilityInfo /CapabilityName:Microsoft.Windows.Sense.Client~~~~

The result should show State : Installed and Version : 10.x.x.x. If State : NotPresent, install the FoD before proceeding.

2. Open Advanced Hunting and run the §8 query

Navigate to defender.microsoft.com (or the legacy security.microsoft.com), expand Hunting > Advanced hunting, paste the §8 KQL query, and run it [@advanced-hunting-overview]. On a fresh tenant the query may return zero rows -- that is the correct result for a healthy environment. Tighten the time window if it is slow (Timestamp > ago(1h) instead of ago(24h)) until the query returns within ten seconds. The point of this step is to confirm the read surface is reachable and that the user has Hunter (or higher) RBAC permission on the tenant.

3. If licensed for Sentinel, install the Defender XDR connector

In the Microsoft Sentinel workspace, navigate to Data connectors, choose Microsoft Defender XDR, and configure per-table streaming [@sentinel-xdr-connector]. Pick the tables your team needs longer retention or analytics-rule scheduling on; leave the others to in-portal Advanced Hunting. Be aware that enabling the connector "automatically disconnects" any legacy Microsoft Defender component connectors during enablement; this is the cleanup detail to plan for during migration windows [@sentinel-xdr-connector].

4. If deploying Sysmon alongside MDE, start from the augment config

Clone olafhartong/sysmon-modular, build the sysmonconfig-mde-augment.xml variant, and deploy with:

Sysmon64.exe -accepteula -i sysmonconfig-mde-augment.xml

Verify the active configuration with Sysmon64.exe -c and confirm the rule count matches the augment config's expected output [@github-hartong-modular].

5. If deploying Sysmon standalone, start from NextronSystems or modular default

For air-gapped or unlicensed environments, clone NextronSystems/sysmon-config (the post-2021-rename successor to Neo23x0/sysmon-config) and deploy sysmonconfig.xml or, for the blocking-rule variant, sysmonconfig-export-block.xml [@github-neo23x0][@github-nextronsystems-meta]. Alternatively, olafhartong/sysmon-modular's default sysmonconfig.xml (built from the modular library) is the right choice if you want fine-grained per-technique tuning later [@github-hartong-modular].

6. Verify Sysmon v15.2 or later is running

Sysmon64.exe -c

The output's header line should show the binary version. Anything v15.x or later has the protected-process gate enabled [@sysmon-ms-learn][@bleepingcomputer-sysmon15]. Anything older is trivially blindable by a SYSTEM-privilege attacker and is the single biggest deployment-hygiene risk in the Sysmon population today.

7. Audit the MDE onboarding registry hives

Compare the live registry values to the expected onboarding state:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection"
reg query "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status"

Unexpected changes -- particularly a change to the onboarding OrgId or to the policy-controlled Disabled value -- are an indicator that the tenant or device has been re-targeted, possibly by an attacker who obtained admin-level access and is attempting to re-route the endpoint's telemetry to a different tenant or to disable the MDE sensor entirely [@sense-troubleshoot]. Set up a Sentinel detection rule on DeviceRegistryEvents with RegistryKey contains "Windows Advanced Threat Protection" to surface this class of tampering automatically.

Note: Walk steps 1 and 2 on a single non-production host before fleet rollout. The ninety-second-triage walk you saw in §1 is best learned by reproducing it once on your own tenant. The cost of getting steps 4-6 wrong (deploying the wrong Sysmon config on a high-volume server fleet) is hours of operational pain; the cost of doing them right on a single test host first is twenty minutes.

The MDE sensor service has not been onboarded on this host. Two common causes: (1) the endpoint is on a Windows Server SKU and the SENSE Feature on Demand has not been installed; run the DISM `Get-CapabilityInfo` check in step 1 to confirm. (2) The onboarding script (the `WindowsDefenderATPLocalOnboardingScript.cmd` or the equivalent Group Policy / Intune / SCCM artifact) has not been run on this host. The MDE settings page in the Defender XDR portal shows the per-device onboarding artifacts under **Settings > Endpoints > Onboarding** for download [@sense-troubleshoot].

The Defender XDR portal also exposes a device timeline view that surfaces a chronological event stream per device without requiring KQL. This is the right view for analysts who are still learning the schema; the KQL surface is the right view for repeatable hunts and detection-rule authoring.

Seven steps, one Monday. The rest of the questions are in the FAQ.

15. Frequently Asked Questions

Seven of the questions that come up every time this material is taught.

Yes on its output side; mostly no on its input side. Sysmon publishes its events through an ETW provider called `Microsoft-Windows-Sysmon`, which is how downstream collectors and the Windows Event Log service consume the data. On its *input* side, Sysmon is a kernel driver that collects via five different mechanisms -- `PsSetCreateProcessNotifyRoutineEx` for process create and exit, `PsSetLoadImageNotifyRoutine` for image load and driver load, `PsSetCreateThreadNotifyRoutineEx` for remote-thread creation, `ObRegisterCallbacks` for cross-process access, `CmRegisterCallbackEx` for registry, and Filter Manager minifilters for ordinary file system and NPFS named pipes. Two exceptions live on Sysmon's input side. The single kernel-ETW consumer is `Microsoft-Windows-DNS-Client` for EID 22 DNSEvent; the WmiEvent family (EIDs 19-21) is implemented in a consumer style against the WMI activity provider's user-mode tracing surface. Calling Sysmon "ETW-based" without that distinction is the most common architectural confusion in the field [@sysmon-ms-learn]. For most organizations licensed for MDE Plan 2 and without a mature detection-engineering team, yes -- MDE alone is the right baseline. For organizations with a detection-engineering team, the community pattern is to deploy MDE *plus* a tuned Sysmon configuration (specifically Olaf Hartong's `sysmonconfig-mde-augment.xml`) that fills the gaps where MDE's `Device*` schema truncates or omits fields that Sysmon's manifest captures verbatim -- the `ProcessAccess` GrantedAccess mask, the full WMI consumer expressions, RawAccessRead, the pipe events, and selected file-delete archival paths. The wrong answer for an MDE-licensed shop with a detection-engineering team is to do nothing on the Sysmon side; the second-wrong answer is to deploy *default* Sysmon alongside MDE, which produces double the telemetry volume for the coverage of one [@github-hartong-modular][@mde-ms-learn]. The five class-specific `Device*` tables (`DeviceProcessEvents`, `DeviceNetworkEvents`, `DeviceFileEvents`, `DeviceImageLoadEvents`, `DeviceRegistryEvents`) each map onto a single Sysmon EID family and present a normalized, per-class set of columns. `DeviceEvents` is the miscellaneous catch-all: AMSI scan results, exploit-protection events, Defender Antivirus operational events, Attack Surface Reduction rule fires, Network Protection blocks, OpenProcess API calls, and other MDE-specific telemetry surface here under different `ActionType` values. If a row's `ActionType` does not match what you expected, the row is probably in `DeviceEvents` rather than the table you searched first [@advanced-hunting-overview]. No. The historical root is SwiftOnSecurity's `sysmon-config`, created on February 1, 2017 per the GitHub REST API [@github-swiftonsecurity-meta]. Florian Roth (`@Neo23x0`) forked SwiftOnSecurity's repository in January 2018 and added blocking-rule support, community pull-request merges, and the maintainer roster that now includes Tobias Michalski, Christian Burkard, and Nasreddine Bencherchali [@github-neo23x0]. The Neo23x0 repository was renamed to `NextronSystems/sysmon-config` on July 24, 2021 [@github-nextronsystems-meta]; the old URL HTTP-301 redirects to the new one and the content lineage from SwiftOnSecurity is unchanged. Calling Roth's config "the original" is the inverse of the truth; calling it "the canonical actively-maintained fork" is closer. No. Sysmon supports one active configuration at a time. There is no aggregate-multiple-XMLs feature at the driver layer. Olaf Hartong's modular workflow generates a single merged XML at build time from a per-technique module library; the production fleet receives that single XML and the driver enforces it. If you want two configurations -- one for the SOC team's hunting, one for the platform team's audit -- merge the rules at build time and ship the combined product [@github-hartong-modular]. Because it runs as Antimalware Protected Process Light (`PROTECTED_ANTIMALWARE_LIGHT`), the Windows kernel rejects ordinary user-mode `OpenProcess(PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_DUP_HANDLE)` requests against the process from any caller that does not itself run at an equal or higher signer level. The published reverse-engineering technique (FalconForce 2022) is to raise the Windows PE debug server `dbgsrv.exe` to the `WinTcb` signer level via a PPLKiller-class kernel primitive, then attach the elevated debug server to `MsSense.exe`. That technique requires a kernel-mode primitive (commonly a BYOVD chain), which is itself non-trivial. The protection level is the structural defense; the debug-server technique is the dispositive community workaround [@falconforce-2022]. Thirty days of raw data in the Defender XDR portal: "*Advanced hunting is a query-based threat hunting tool that you use to explore up to 30 days of raw data*" [@advanced-hunting-overview]. Beyond thirty days, retention is configurable per workspace via the Microsoft Sentinel Defender XDR connector; the Log Analytics workspace archive tier supports up to twelve years of per-table archive on a per-GB-billed basis [@sentinel-xdr-connector][@ms-log-analytics-archive]. The two surfaces are not exclusive; the common operational pattern is in-portal for the hunting team (30 days, no per-GB cost) plus per-table Sentinel streaming for the analytics-rules team (extended retention, per-GB cost on selected tables).

These are the questions. The seven layers between Maya's cmd.exe at 9:14 a.m. and her Kusto row at 9:14:03 are how the answers actually work -- a kernel callback, a user-mode aggregator, an ETW publisher or TLS-pinned cloud forwarder, a regional Kusto ingest, a table write, and a KQL read, with two structural defenses (Antimalware-PPL and the Sysmon v15 protected-process gate) keeping each layer honest. Every other detection-engineering pattern in the Windows field is a configuration of those seven layers, and most of the open problems are at the seams between them.

See also. The Sysmon driver's collection layer leans on the kernel-callback APIs documented in the Windows process mitigations and Object Manager namespace articles in this series. The ETW transport bus that Sysmon publishes onto -- and that EtwTi security events surface through -- is the subject of the dedicated ETW article in this series; the article goes deeper on provider GUIDs, manifests, and the eight-trace-session manifest-provider cap that bounds Sysmon's coexistence story in §10. The AMSI primary path that produces DeviceEvents ActionType = "AmsiScriptDetection" is the subject of the AMSI article; the two pipelines are siblings, not substitutes. And the Sigma rule corpus that compiles down into KQL for Defender XDR / Sentinel hunting is the same Sigma corpus that compiles into Splunk SPL and Elastic EQL -- the vendor-neutral query layer that sits above this article's KQL surface [@github-sigma].