EDR Silence Escalation

Purpose: Procedure for when Cortex XDR returns zero findings during a cycle where other kill chain agents have elevated detections.

Audience: Rory Triggered by: defense_evasion_agent in bedrock-hub, finding resource = CORTEX-XDR

---

What This Alert Means

The defense evasion agent checks whether Cortex XDR's finding count is zero in the same cycle that the execution, lateral movement, or credential dumping agents have fired HIGH or CRITICAL findings. When all three conditions are true simultaneously:

1. Kill chain agents found something serious
2. Cortex XDR, which should detect the same activity, found nothing
3. The Cortex agent ran successfully (confidence > 0) — so it's not a collection failure

This is a compound signal. It could mean:

• Attacker evaded or disabled Cortex — high-confidence attack scenario
• Cortex sensor is unhealthy on the affected host — less critical but still needs remediation
• Kill chain finding is a false positive — if the kill chain finding has no corroborating evidence, this is likely

---

Immediate Triage (5 Minutes)

1. Open the SecOps finding. Note: which kill chain agent fired, which host, which account
2. Open Cortex XDR console: https://ciriusgroup.xdr.us.paloaltonetworks.com
3. Check Incidents and Alerts — is Cortex actually silent, or is it generating alerts that are not flowing to SecOps?
4. If Cortex has incidents/alerts that match the kill chain activity → the issue is in the ingestion pipeline, not Cortex itself (see below)
5. If Cortex console is genuinely silent for that host → investigate sensor health

---

Scenario A — Ingestion Pipeline Failure

Cortex console shows alerts but SecOps shows no Cortex findings.

1. Check cortex_agent.py logs in Container Apps Job:

   ContainerAppConsoleLogs
   | where TimeGenerated > ago(6h)
   | where ContainerName contains "cortex"
   | project TimeGenerated, Log
   | order by TimeGenerated desc

2. Look for API errors, authentication failures, or HTTP 5xx from the Cortex API
3. If the agent logged confidence: 0 — the Cortex API was unreachable. This is an infrastructure issue, not an attack
4. Remediate: check Cortex API credentials in Key Vault (cirius-openai-kv-prod → cortex-api-key), check network connectivity from Container App to Cortex API endpoints
5. Re-trigger the agent manually after fixing the connectivity issue

---

Scenario B — Cortex Sensor Unhealthy

Cortex console shows the endpoint as Disconnected or Last Seen > 2 hours.

1. In Cortex console → Endpoints → search for the affected host → check Agent Status and Last Seen
2. If status is Disconnected:
   • Check if the VM is running (see runbooks/vm-status-agent.md)
   • If the VM is running but Cortex is disconnected: check Cortex service status on the endpoint
   • From an admin workstation: Get-Service "CortexXDRSvc" -ComputerName <hostname>
   • If service is stopped: Start-Service CortexXDRSvc -ComputerName <hostname>
3. If the service won't start: treat as potential attacker interference (Scenario C)

---

Scenario C — Cortex Sensor Disabled or Evaded (Active Attack)

Cortex service is stopped, failed to start, or the Cortex process was terminated. Combined with active kill chain findings on the same host.

This is the highest-confidence EDR silence scenario. Attackers disable EDR before detonating payloads.

Immediate actions:

1. Notify Rory via Telegram immediately — do not wait
2. Notify Arctic Wolf — Arctic Wolf MDR has independent visibility via their own agent and Azure audit logs. Call the Arctic Wolf hotline or open a priority case in the Arctic Wolf portal. Arctic Wolf can act without approval for containment
3. Isolate the affected host:
   • Cortex: even if the Cortex agent is down, the console may still allow isolation if the management channel is intact — try it
   • Arctic Wolf: request they isolate the host if Cortex console isolation fails
   • Intune: for managed workstations — Intune → Device → Actions → Retire/Wipe as a last resort
4. Do not restart the Cortex service from a network-connected admin session — the host may be compromised and the admin session may be monitored
5. Preserve the host state before any changes — snapshot the disk if possible, export Cortex event history

---

Scenario D — Kill Chain False Positive

No other evidence of attack. The kill chain finding has characteristics of a false positive (e.g., a known software update triggered the LOLBin detection).

1. Review the kill chain finding evidence: command line, parent process, account — does this look like a legitimate software action?
2. Check CM tickets for the host around that time
3. If it's a confirmed false positive:
   • Add a known-good rule in SecOps for the specific ioc_key
   • The EDR silence finding resolves automatically when the kill chain finding is closed
   • Document the false positive root cause to improve future detection

---

Escalation

Condition	Action
Cortex API pipeline down	Fix ingestion, no immediate escalation needed
Cortex sensor disconnected	Reconnect and investigate cause; escalate to Rory if no clear reason
Cortex service stopped — no explanation	CRITICAL — Rory + Arctic Wolf immediately
Cortex evaded during active kill chain activity	CRITICAL — Rory + Arctic Wolf — isolation required

---

Post-Incident

• If sensor was tampered with: open a Palo Alto support case for forensic analysis of how the agent was bypassed
• Document in SecOps incident: timeline, how Cortex was silenced, what was visible in LAW that Cortex missed
• Review whether additional KQL-based detection can compensate for Cortex gaps in this scenario
• HIPAA: if ePHI host involved and attacker successfully evaded detection, initiate breach risk assessment

---

Related Documents

• runbooks/kill-chain-defense-evasion-response.md — response to the defense evasion finding that triggers this runbook
• runbooks/cortex-xdr-operations.md — Cortex XDR console operations
• security/edr-cortex-xdr.md — EDR architecture
• runbooks/incident-response.md — full IR plan