What Is an XDR?

EmailAttachmentInfo.SHA256 is the field you would join on to prove that a phishing attachment executed on an endpoint. Microsoft's own schema reference says that field is usually not populated and tells you to use the SHA1 column instead. The canonical XDR demo, email to endpoint by file hash, runs on SHA1 in the product that coined half the category's marketing.

That footnote is the whole subject. XDR is the most marketing-loaded acronym in security operations, so define it by the work it has to do rather than by the datasheet.

The definition worth arguing with

The term was coined by Nir Zuk of Palo Alto Networks in 2018. Gartner's version, from the 2023 Market Guide for Extended Detection and Response, is the one most vendors are measured against:

Extended detection and response (XDR) delivers security incident detection and automated response capabilities for security infrastructure. XDR integrates threat intelligence and telemetry data from multiple sources with security analytics to provide contextualization and correlation of security alerts. XDR must include native sensors, and can be delivered on-premises or as a SaaS offering. Typically, it is deployed by organizations with smaller security teams.

Note the four words doing the heaviest lifting: XDR must include native sensors. By that definition every product marketed as "open XDR" is something else. Hold that thought, it comes back.

Strip the rest and one testable claim remains. An XDR takes signals from endpoint, identity, email, cloud and network, and joins them into a single incident with a shared timeline. If a product cannot show you an attachment delivery, the sign-in that followed, and the process that ran, in one object, ordered by time, it is a console with tabs.

The join is the product

Correlation across domains is a database join. Joins need keys. Most XDR discussions skip straight to machine learning and never name the keys, which is how you end up buying something that cannot correlate.

Here are the real ones, from the Microsoft Defender XDR advanced hunting schema. We use it as the reference because the schema is public and the column names are exact.

Read the identity row against the endpoint row. IdentityLogonEvents carries AccountObjectId, the Entra ID object ID. DeviceLogonEvents does not carry it for the account that logged on. It carries InitiatingProcessAccountObjectId, which is the account that ran the process responsible for the event, not the logon subject. So the email-to-endpoint pivot on identity has to route through AccountSid or through UPN string matching, and one of those two is a string comparison against user-controlled casing.

The attachment-to-endpoint join looks like this. Written as a hunt, not as a product feature.

let delivered = EmailAttachmentInfo
| where Timestamp > ago(7d)
| where isnotempty(SHA1)
| project MailTime = Timestamp, NetworkMessageId, RecipientObjectId,
          RecipientEmailAddress, SHA1, FileName;
let onDisk = DeviceFileEvents
| where Timestamp > ago(7d)
| where isnotempty(SHA1)
| project FileTime = Timestamp, DeviceId, DeviceName, SHA1, FolderPath;
delivered
| join kind=inner onDisk on SHA1
| where FileTime between (MailTime .. MailTime + 4h)
| project MailTime, FileTime, RecipientEmailAddress, DeviceName, FileName, FolderPath, SHA1

That is T1566.001, Spearphishing Attachment, correlated to file write on a managed host. Four lines of join and one time window. Everything a vendor sells as cross-domain correlation is a more general version of this, plus scoring, plus a UI.

When the identifiers do not exist

The join above fails silently in more situations than it succeeds in. Naming them is more useful than any capability matrix.

Cloud-only accounts have an Entra ID object ID and no on-premises SID that means anything to an AD-joined endpoint. If your identity signal is keyed on object ID and your endpoint signal is keyed on SID, T1078.004 activity on a cloud-only account joins to nothing on the endpoint side.

Device identity is a string. IdentityLogonEvents gives you DeviceName as an FQDN. DeviceLogonEvents gives you both DeviceId and DeviceName. Joining on the name works until a host is renamed, appears as a NetBIOS short name, or is not onboarded at all. Note also that DeviceLogonEvents collection is not supported on Windows 7 or Server 2008R2 hosts onboarded to Defender for Endpoint, so those hosts contribute nothing to the endpoint side of any join.

Network signals are the weakest link because their only common key is usually an IP address and a timestamp. Behind NAT, or on a VPN concentrator handing out addresses from a pool, an IP identifies a range of possible users. T1021.001 over RDP from an internal address is a join on RemoteIP plus a time window, which is a probabilistic match rather than an identity match.

Unmanaged hosts do not appear at all. No correlation recovers a device with no sensor on it.

Native versus open

Native XDR means the vendor owns the sensors. The endpoint agent, the identity connector and the mail gateway all emit into one schema the vendor designed, so the identifiers line up by construction. That is genuinely easier, and Gartner's definition requires it.

Open XDR means the correlation layer sits above sensors you already own. The join is not free any more, so something has to normalize the fields first. That is what OCSF, the vendor-neutral event schema from the Open Cybersecurity Schema Framework project, and ECS on the Elastic side exist to solve. ECS ships a field set for exactly this problem: related.ip, related.user, related.hosts and related.hash are arrays holding every value seen anywhere in an event, so a pivot works without knowing which of a dozen fields the value landed in.

{
  "related": {
    "user": ["jsmith", "CORP\\jsmith", "jsmith@corp.example"],
    "hosts": ["ws-4471", "ws-4471.corp.example"],
    "ip": ["10.4.19.22", "203.0.113.44"],
    "hash": ["a94a8fe5ccb19ba61c4c0873d391e987982fbbd3"]
  }
}

The tradeoff is honest on both sides. Native gets you working joins on day one and gets you lock-in, because the correlation logic that produced the incident is the vendor's, and it does not come with you when you leave. Open gets you portability and hands you the normalization bill. There is no configuration that avoids the choice.

What XDR does that a SIEM with good content does not

Less than the marketing implies, and more than the cynics allow.

A SIEM with a maintained detection library and normalized data can run every query in this post. Correlation across sources is not a new capability, it is what correlation rules have done since the term existed. If you have a working SIEM and a detection engineering practice, the incremental capability of XDR is smaller than the invoice suggests.

Three differences are real. Native sensors mean the schema problem is solved before you arrive, and schema work is where most SIEM programs actually die. Response lives in the same product as the detection, so isolating a device or revoking a session is one action rather than an integration. And the vendor ships and maintains the correlation content, which matters if you have two analysts and no detection engineer.

The cost of the third one is the point of this post. Vendor correlation logic is almost always opaque. You get an incident with a confidence score and a graph, and no way to read the predicate that produced it.

Correlation you cannot inspect is correlation you cannot tune

Write the cross-domain logic yourself where you can, so the predicate stays readable. Sigma supports this through correlation rules, which chain existing rules with a grouping key and a time window.

title: Phishing Attachment Delivered Then Interactive Logon From A New Device
id: 7a1c3f92-4e6b-4d18-b5c0-2f9d8e4a1b73
status: experimental
description: Correlates delivery of a flagged mail attachment with an interactive logon by the same user from a device not previously seen for that account.
author: huntrule.com
date: 2026-07-31
correlation:
    type: temporal_ordered
    rules:
        - mail_attachment_flagged
        - identity_logon_unseen_device
    group-by:
        - User
    timespan: 4h

What it catches: the delivery-then-account-use sequence, in order, within four hours, for one user. Ordering matters. The reverse sequence is noise.

What it misses: everything where the two base rules do not emit a User field with the same shape. If mail_attachment_flagged emits a mail address and identity_logon_unseen_device emits a UPN, the group-by silently produces zero groups rather than an error. Test both base rules in isolation first and confirm the field values match character for character. Backend support for Sigma correlations is uneven across pySigma backends, so check yours before you build a program on it.

Known false positives: shared mailboxes and distribution lists, where RecipientEmailAddress expands to many users. Bulk mail campaigns to a whole department during a normal working day. New-hire onboarding, which produces exactly this pattern for legitimate reasons, first mail, first logon, unfamiliar device.

We did not test this correlation against a live Defender tenant. The base logic and the field names are taken from published schema documentation, not from telemetry we collected.

The question to ask a vendor

One question separates a correlation engine from a correlation demo. Show me the joining logic for an incident, and let me change it.

If the answer is a graph and a confidence score, you have bought output you cannot tune, and when the join produces a false positive at scale your only lever is suppression. If the answer is a query or a rule you can edit and version, you have bought something a detection engineer can own. Ask before the proof of concept, not after.

Summary

XDR is cross-domain correlation with native sensors, and that correlation is a join on shared identifiers: Entra ID object IDs, AD SIDs, file hashes, device names and IP addresses. Each one fails in knowable situations, including cloud-only accounts, renamed hosts, NAT, unmanaged devices, and a SHA256 column that is usually empty. Native XDR solves the schema problem and creates lock-in, open XDR preserves portability and hands you the normalization work. The overlap with a well-run SIEM is large, and the real differentiators are packaged sensors, integrated response and maintained content. Judge any XDR on whether you can read and modify the logic that joined the events.

Fields to collect before you attempt any of this:

Email     EmailEvents.NetworkMessageId, RecipientObjectId, RecipientEmailAddress
Email     EmailAttachmentInfo.SHA1, SHA256, FileName, NetworkMessageId
Identity  IdentityLogonEvents.AccountObjectId, AccountSid, AccountUpn, DeviceName, LogonType
Endpoint  DeviceLogonEvents.AccountSid, AccountName, AccountDomain, DeviceId, DeviceName, RemoteIP
Endpoint  DeviceFileEvents.SHA1, SHA256, DeviceId, FolderPath
ATT&CK    T1566.001, T1078.004, T1021.001

Identity is where most cross-domain joins break first. The identity rules in our catalog are at /rules?domain=identity, and the email side is at /rules?domain=email.