Operational Exception without Case

[M.Wempen]

We are currently facing an issue with a Windows service. This service only functions properly after we add a specific executable (.exe) to the Operational Agent Exceptions . We haven’t seen any corresponding case or alert in the console, meaning Cortex XDR is not actively blocking anything.

This raises the following questions:

1) Wildcards in Operational Agent Exceptions

Unfortunately, wildcards cannot be used in the Operational Agent Exceptions profile. Is there any plan to support wildcards for these exceptions in the future?

2) Module Identification & Support Files

A more granular Process Exception would be highly preferred over a blanket operational exception. To achieve this, we obviously need to identify which specific module needs to be disabled for this process.

• What is the best troubleshooting workflow to determine this?

• How can we extract this information from the Support Files?

3) Best Practice for Single-Endpoint Exceptions

This exception is intended for a single server only. To apply this single operational exception, we currently have to create a separate policy row containing a Malware, Restriction, and Agent Setting profile. Is creating a completely dedicated policy structure for a single endpoint really considered best practice? Over time, managing exceptions this way makes the policy overview difficult to maintain.

Thank you 🙂

[susekar]

Hello @M.Wempen ,

Greetings for the day.

Here are the answers to your questions regarding Windows service issues and Operational Agent Exceptions:

1. Wildcards in Operational Agent Exceptions:

Wildcards are supported in Operational Agent Exceptions for Windows endpoints starting with Cortex XDR Agent version 8.7 and above.

The supported wildcard syntax includes:

• Simple Wildcards: Use an asterisk (*) to represent any string. For example:
  • C:\temp\*
  • *\temp\*
• Partial Match: You can use:
  • *filename*
  • *filename.exe
• Recursive Wildcards: For deep path structures, recursive wildcards can be used for path matching.

If wildcards are failing in your environment, ensure you are running a supported agent version (8.7+) and that the path is specified as an absolute path or matches one of the supported patterns.

2. Module Identification & Support Files:

When a service is silently failing without generating a console alert, it is typically caused by an operational conflict with a monitoring or injection module.

Troubleshooting Workflow:

The recommended approach is methodical component isolation:

1. Isolate High-Level Modules
   Create a test policy for the endpoint and disable the following modules one at a time:
   • Anti-Exploit Protection (Exploit Profile)
   • Malware Protection (Malware Profile)
   • Event Collection (Agent Settings)
2. Granular EPM Isolation
   If the conflict originates from the Exploit Profile, use Legacy Agent Exceptions to disable specific Exploit Protection Modules (EPMs) for the process individually (for example, DllSec, R01, Ransom, or Shellcode Intercept).
3. Process Restart
   Always restart the affected service or application after applying an exception, as protection hooks are typically injected during process startup.
   
   

Extracting Information from Support Files (TSF)

To identify the root cause, review the following files within the Tech Support File:

• Application.evtx
  • Search for Event IDs 1000 or 1001 to identify the executable and faulting module.
• CyveraSystem.reg
  • Search for the process name and verify the Protect value.
  • A value of dword:00000001 confirms that Cortex XDR is injected into the process.
  • Review the list of enabled component codes under the process key.
• trapsd.log
  • Search for the module name or entries such as "Trusted by admin" to determine whether an existing exception is being matched or ignored.

3. Best Practice for Single-Endpoint Exceptions:

Creating a dedicated policy for a single endpoint is possible but may increase management overhead.

Recommended approaches include:

• Granular Alert Exceptions

  • Instead of broad Operational Exceptions, use Alert Exceptions or Disable Prevention Rules targeted by:
    • SHA256 hash
    • Signer
    • File path

  This minimizes security risk by limiting the exception to a specific binary version rather than excluding an entire process.

• Centralized Exception Profiles
  • Use centralized exception profiles to manage related exceptions across multiple modules from a single location.
• Policy Scoping
  • Use Endpoint Tags or dedicated Endpoint Groups for specific server types.
  • Apply the special policy to the group or tag instead of individual hostnames to maintain a logical and scalable policy structure.

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