Cortex XDR Day-to-Day Operations

Overview

How to use the Cortex XDR console for daily operations — reading alerts, investigating behavioral detections, checking endpoint health, managing exclusions, and responding to agent issues.

For coverage, architecture, and MDE passive mode configuration see Cortex XDR — EDR Architecture.
Cortex XDR findings surface in SecOps via cortex_agent.py every 4 hours. For triage workflow see SecOps Findings Triage Guide.

Console URL: https://ciriusgroup.xdr.us.paloaltonetworks.com
Login: Cortex XDR admin credentials in Keeper → Vendor Accounts → Cortex XDR Admin

---

Console Navigation

Section	What's Here
Incidents	High-level incident groupings — Cortex correlates related alerts into incidents
Alerts	Raw alert feed — every individual detection
Investigation → Causality View	Process tree for a specific alert — see the full execution chain
Endpoints	All enrolled devices — health status, agent version, last seen
Response	Live terminal, file retrieval, network isolation actions
Policies	Prevention and agent policies — what's being blocked vs alerted
Exclusions	Process, file, and network exclusions

---

Reading Alerts

Alert Feed

Alerts → set time range → filter by Status: New or Under Investigation

Each alert shows:

• Severity — High, Medium, Low, Informational
• Alert name — the detection type (e.g., "Credential Dumping via LSASS Access")
• Endpoint — which machine
• Actor process — the process that triggered it
• Action taken — Prevented (blocked), Detected (logged only), or Reported

Cortex groups related alerts automatically into Incidents. Start with the Incidents view for a higher-level picture — an incident shows you multiple correlated alerts that may indicate a single attack chain.

Causality View (Process Tree)

The most useful view for understanding what happened:

1. Click any alert → View in Causality
2. The causality view shows the full process tree: what parent spawned what child, what files were accessed, what network connections were made
3. Read bottom-up: the leaf node is the malicious action; the parent chain shows how it got there

Use this to answer: "Is this a real attack, or is this a legitimate process doing something unexpected?"

Alert Severity Reference

Severity	Meaning	Default Response
High	Likely malicious — active threat or significant risk	Review same day; escalate if you can't rule it out
Medium	Suspicious but may be benign — needs context	Review within 48h
Low	Informational or low confidence	Review weekly

Cortex alerts that the cortex_agent.py surfaces in SecOps are pre-filtered to High and Critical. Medium and Low alerts are visible in the Cortex console but don't automatically create SecOps incidents.

---

Checking Endpoint Health

Fleet Overview

Endpoints → All Endpoints

Key columns:

• Status — Connected (active), Disconnected (offline)
• Last Seen — when the agent last checked in
• Agent Version — should match the current deployed version
• Protection Status — Protected, Unprotected (agent installed but not fully active)

Filter to Status = Disconnected and Last Seen > 24h ago to find endpoints that may have lost the agent or been powered off.

Single Endpoint Detail

Click any endpoint to see:

• Overview — OS, IP, last user, last seen
• Alerts — all alerts for this endpoint, any time range
• Incidents — incidents involving this endpoint
• Agent Status — agent health, module versions, policy applied

If an endpoint shows Unprotected: the agent is installed but a module (e.g., prevention engine) failed to start. Usually fixed by restarting the Cortex XDR service on the endpoint:

# On the affected endpoint
Restart-Service -Name CyveraService

Cortex Agent Silence Alert

When cortex_agent.py fires "0 alerts from Cortex XDR" for a full 4-hour cycle despite other activity, this is the EDR silence detection — check:

1. Cortex console → Endpoints → is every expected machine showing as Connected?
2. Is the agent version current? An outdated agent may not be reporting correctly.
3. Is the Cortex XDR service running on the endpoint? Check via RDP or Twingate.

---

Investigating a High-Severity Alert

Step 1 — Open the Alert

Cortex console → Incidents (or Alerts) → click the alert.

Read: Alert name, severity, endpoint, actor process, what action was taken.

Step 2 — View the Causality Tree

Click View in Causality. Expand the tree. Look for:

• Unusual parent-child relationships (Word spawning PowerShell, Explorer spawning cmd)
• Processes running from temp or AppData directories
• Network connections to external IPs from unexpected processes
• File writes to system directories from user-space processes

Step 3 — Cross-Reference with KQL

Pull the same time window in Log Analytics to see what else was happening:

SecurityEvent
| where TimeGenerated between (datetime('2026-05-25T10:00:00Z') .. datetime('2026-05-25T11:00:00Z'))
| where Computer == "AFFECTED-HOSTNAME"
| where EventID in (4688, 4624, 4648, 7045, 4698, 1102)
| project TimeGenerated, EventID, Account, NewProcessName, CommandLine
| sort by TimeGenerated asc

Step 4 — Decide

Real threat: Change alert status to Under Investigation → notify Rory → follow Incident Response → consider network isolation (see below).

False positive: Change status to Resolved with a note → consider adding an exclusion if this specific detection fires regularly for the same legitimate process.

---

Network Isolation

If an endpoint is actively compromised, isolate it to cut off C2 communication while preserving it for forensics:

1. Endpoints → select the affected endpoint
2. Response → Isolate → confirm
3. The endpoint is cut off from all network except the Cortex XDR management channel (so you can still remote in via Cortex Live Terminal)
4. Document the isolation time in SecOps
5. Do not wipe or shut down — memory contains forensic evidence

To remove isolation after remediation: Endpoints → select endpoint → Response → Remove isolation

---

Live Terminal (Remote Access via Cortex)

For forensic investigation or remediation on an endpoint without needing Twingate or RDP:

1. Endpoints → select endpoint → Response → Live Terminal
2. A terminal session opens in the browser — runs as SYSTEM
3. Use for: collecting files, running commands, checking processes

# Common forensic commands
Get-Process | Select-Object Name, Id, Path, StartTime | Sort-Object StartTime -Descending
Get-NetTCPConnection | Where State -eq Listen
Get-ScheduledTask | Where State -eq Ready | Select TaskName, TaskPath

Live Terminal sessions are logged in Cortex audit logs.

---

Managing Exclusions

Exclusions tell Cortex to stop alerting on a specific process, file hash, or network connection that is known-benign.

When to Add an Exclusion

Only after verifying the behavior is genuinely benign. Common legitimate exclusions:

• Backup software processes that Cortex interprets as credential access
• Custom scripts that spawn child processes in ways that match malicious patterns
• Security tools (Velociraptor, Arctic Wolf VLC) that behave like attack tools

Do not add exclusions for:

• Processes you haven't fully investigated
• Broad exclusions like "all PowerShell" or "all from C:\Temp"
• Anything related to a known-malicious process in an incident

Adding a Process Exclusion

Policies → Exclusions → Add Exclusion → Process Exclusion

• Process name or SHA256 hash (hash is preferred — more specific)
• Optionally scope to specific endpoints or groups
• Add a description: why this is excluded, what verified it's benign, date

All exclusions require Rory's approval — document the justification before requesting.

---

Policy Overview

Policies → Prevention Policies

Current policy mode: Prevention (blocks known-malicious behavior) with behavioral detection enabled (alerts on suspicious but not definitively-malicious behavior).

Module	Mode	What It Does
Malware prevention	Prevention	Blocks known malware by hash/signature
Exploit prevention	Prevention	Blocks exploit techniques (heap spray, ROP, etc.)
Behavioral threat protection	Detect + Prevent	Detects attack behaviors; critical ones auto-blocked
Credential gathering	Detect + Prevent	LSASS access, credential theft techniques
Ransomware protection	Prevention	Blocks mass file encryption behavior

Do not change policy modes without Rory's approval. Switching from Prevention to Detect-only significantly reduces protection.

---

Agent Version Management

Cortex agent updates are managed through the Cortex console, not via Intune or WSUS.

Endpoints → Agent Versions → shows current vs target version for each endpoint.

To update agents:

1. Endpoints → select endpoints to update (test on a non-critical endpoint first)
2. Actions → Update Agent Version
3. Monitor for a few hours — verify no endpoints report issues post-update
4. Roll out to remaining endpoints

Agent updates typically don't require a reboot, but some module updates do. Schedule during low-activity hours if a reboot is expected.

---

Troubleshooting

Agent Showing as Disconnected

1. Verify the endpoint VM is running (Azure Portal or direct check)
2. Check network connectivity — Cortex agent requires outbound HTTPS to crtxsiem.us.paloaltonetworks.com and related Palo Alto cloud endpoints
3. Verify the Palo Alto DNS Security isn't blocking Cortex endpoints (known issue — see edr-cortex-xdr.md for the FQDN resolution gap)
4. On the endpoint: check Cyveraservice is running:

   Get-Service CyveraService

Agent Installed But "Unprotected"

One or more prevention modules failed to start. Usually a file lock or leftover from a previous install:

1. Restart CyveraService (above)
2. If that doesn't fix it: uninstall and reinstall the agent. Get the installer from Cortex console → Endpoints → Agent Installations → Download

MDE Conflict (High CPU)

If an endpoint shows high CPU and both Cortex and MDE are visible in processes, MDE has switched out of Passive Mode. Fix:

# Verify MDE is in passive mode
Get-MpComputerStatus | Select AMRunningMode
# Should be: Passive

# If Active — force passive:
Set-MpPreference -DisableRealtimeMonitoring $true

---

Related Documents

• Cortex XDR — EDR Architecture — coverage, exemptions, MDE passive mode
• SecOps Findings Triage Guide — how Cortex alerts surface in SecOps
• Incident Response — what to do when Cortex finds something real
• KQL Query Reference — correlate Cortex alerts with LAW logs

---

Document History

Date	Change	Author
May 2026	Initial draft — console navigation, alert reading, endpoint health, investigation workflow, isolation, live terminal, exclusions, policy overview, agent updates, troubleshooting.	Rory