no incidents generated since May 20?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

no incidents generated since May 20?

L1 Bithead

Our Cortex XDR instance stopped generating incidents when detecting malware and other threats. (Somewhat similar to "Cortex XDR - Blocked Hashes on newer systems do not show in Incidents" - except in our case, this is across the board on all devices, for all threats and behaviors.)

(If we initiate a malware scan on the affected device, an incident is generated 🟢 for the same file that was previously blocked by Cortex with no incident. I.e. this tells us the incident creation system is not broken - rather, the usual mechanism of creating incident upon detection or blocking is not working for some reason.)

The first assumption is that something has changed on our side - i.e. we accidentally created a policy (or deleted or disabled an existing policy) - which killed the incident generation mechanism.

The 2nd - that something has changed on the back end w/o our involvement resulting in the above change of behavior.

This seems to have occurred sometime in May 2026.

  • The last auto-generated incident was on May 20 with no such incidents since.
  • Usually we get at least a few incidents a week - so this is unusual.
  • Several users reported blocking by Cortex XDR in late May and early June - but no incidents.
  • No known changes that could have resulted in this change of behavior on our side. (That said, can't rule out an accidental change.)
  • Initiating a malware scan on the machine on which malware was detected or blocked - resulted in incidents generated for the same files that were blocked.

In either case - where do we go to try to figure out what happened, when, and how to fix it? (Please be gentle and patient - Cortex XDR is just a small part of things on my plate, and I will likely not understand something like "go fix your BIOCs".)

Thank you!

5 REPLIES 5

L1 Bithead

Given what you're describing ---> still getting blocked in real time, zero incidents, but a manual scan on the same file does produce one — that points at something suppressing the alert from ever being saved, not a broken detection engine. Check these in order:

1. Settings → Exception Configuration → Alert Exclusions. Sort by Modification Date, look for anything touched around May 15–20. This is my top suspect: an Alert Exclusion rule suppresses matching alerts from being saved/shown in the console (and from creating incidents) — but the agent keeps enforcing the block locally on the endpoint regardless. That's exactly your symptom. If the exclusion criteria happens to only match real-time detections and not on-demand scan results, that also explains why your manual scan still produces an incident for the same file.

2. Settings → Management Auditing. Filter the date range to May 15–20 and Type = "Alert Exclusions" / "Alert Rules" / "Prevention Policy Rules" / "Rules Exceptions". This log keeps 365 days of every admin change with enough detail to see exactly what changed and roll it back. This settles "did we do this to ourselves" either way.

3. Settings → Health Alerts (or Incident Response → Incidents → Alerts Table → switch the view to "Health Domain"). Look for a Correlation-type health alert around your cutoff date — that means the rule that turns detections into incidents is failing silently. Right-click it → "Investigate Correlation Auditing" to see which one broke. Also check for an Ingestion-type alert, which would mean the underlying data feed itself dropped.

If none of the three show anything, open a TAC case with one blocked-but-no-incident file hash + endpoint + timestamp, plus the manual-scan counter-example — that combination is specific enough that support can go straight to the backend pipeline instead of starting from scratch.

Thanks, already got near-identical responses from a couple of chat agents - and that didn't go anywhere.

Which chat agent was this?

Claude Fable 5

L5 Sessionator

Hello @Alex.Gerulaitis ,

 

Greetings for the day.

 

Based on the symptoms you described—where Cortex XDR is successfully blocking threats on endpoints but is not generating incidents in the management console, while manual scans continue to generate incidents—the most likely causes are an Alert Exclusion configuration or changes to the incident creation or alert severity settings.

 

Since you mentioned that you are not the primary XDR administrator, the following checks can help identify the cause.

 

1. Check for Alert Exclusion Rules (Most Likely)

An Alert Exclusion allows the agent to continue blocking threats while preventing the corresponding alert from being reported to the management console. This aligns with your observation that threats are blocked but no incidents are created.

To verify:

  1. Log in to the Cortex XDR console.
  2. Navigate to Settings → Configurations → Alert Exclusions.
  3. Review any active exclusion rules, especially those created or modified around the time the issue began.
  4. Look for broad exclusions related to Malware or Prevented actions.
  5. If an overly broad exclusion is found, temporarily disable it and verify the behavior using a known safe malware test file.

2. Verify the Alerts Table

Cortex XDR differentiates between Alerts (individual detections) and Incidents (groups of related alerts). Depending on your incident creation settings, lower-severity alerts may not be promoted to incidents.

To verify:

  1. Navigate to Incident Response → Alerts.
  2. Review alerts generated during the affected time period.
  3. If detections appear in the Alerts table but not as incidents, review their severity and determine whether they meet the criteria for incident creation.

3. Review Management Audit Logs:

Management Audit Logs can help determine whether any policy or configuration changes were made around the time the issue started.

To verify:

  1. Navigate to Settings → Audit Logs → Management Audit.
  2. Filter the logs for the timeframe when the issue first occurred.
  3. Review any changes related to policies, configurations, or alert exclusions.

4. Review Incident Creation Rules:

Incident creation rules determine which alerts are promoted into incidents.

To verify:

  1. Navigate to Incident Response → Incident Configuration → Incident Creation Rules.
  2. Confirm that the rules responsible for Malware or Analytics detections are enabled.
  3. Verify that the incident creation criteria have not been restricted to only specific severity levels.

If all of the above settings appear to be configured correctly and the issue persists, we recommend collecting the relevant logs and opening a support case for further investigation.

 

 

If you feel this has answered your query, please let us know by clicking like and on "mark this as a Solution".

 

Thanks & Regards,
S. Subashkar Sekar

No AI responses please.

  • 120 Views
  • 5 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!