mass updates to Cortex XDR - Windows coverage

[blb142857]

EDR Telemetry Pull Request

Contribution Details

This is mass update to Cortex XDR capabilities. Each of below capabilities will be explained in the additional notes below

Telemetry Validation

Telemetry collection is either validated running XQL queries (screenshots attached) or through reference to official documentation

Documentation or Evidence:

• [X ] Official documentation (link: )
• [X ] Screenshots attached
• Sanitized logs provided
• Private documentation (will share confidentially)

Type of Contribution

• Adding telemetry information for an existing EDR product
• Adding a new EDR product that meets eligibility criteria
• Proposing new event categories/sub-categories
• Documentation improvement
• Tool enhancement

Validation Details

EDR Product Information

• EDR Product Name: Cortex XDR
• EDR Version: 9.0.0.16757 (latest)
• Operating System(s) Tested: Windows

Testing Methodology

Each of the XQL queries can be run in any Cortex XDR or Cortex \ XSIAM environments with agents running

Additional Notes

For each of the proposed changes, below is its justification

Process Activity -> Process Call Stacks (current: No / Proposed: Yes)
Evidence Type: documentation
Link: https://docs-cortex.paloaltonetworks.com/r/Cortex-XQL-Schema-Reference-Guide/Action-Actor
--> Above documentation highlights the tracking of stack activity as illustrated, for instance by event_resolved_stack_trace field which provides the stack trace related to the event (note: Many fields in this doc can be seen tracking stack activiites)

Process Activity -> Win32 API (current:Pending Response / Proposed: Yes)
Evidence: Screenshot
Below screenshot demonstrate how Cortex XDR records WIN32 API calls through syscalls

File Manipulation -> File Opened (current:No / Proposed: Yes)
Evidence: Screeshot
Below screenshot shows a XQL query demonstration Cortex XDR capabilities recording FILE OPEN events

Network Activity -> URL (current: No / Proposed: Yes)
Evidence: Screenshot
URL is collected throuh agent DPI capabilities in https_data field. In order to specifically show that capability, below XQL query manipulates the http_data json field to extract the URL

Network Activity -> File Downloaded (Current: No / Proposed: Yes)
Evidence: Screenshots (x2)
First screenshot is a XQL query illustrating our use of the mark of the web to track file downloaded. Second screenshot comes from Cortex XDR causality chain where we can see the last writer actor (also available in XQL) and which can pivots to it in order to track the source of the file; this is tracked through file attributes.

Hash Algorithms -> JA3/JA3S (current: No /Proposed: Yes)
Evidence: Screenshot
JA3/JA3S are collected by Cortex XDR DPi capabilities and are stored in the ssl_data ( same capability discussed above for URL). The screenshot below shows extraction from that json fields of those hashes

Schedule Task Activity -> Scheduled Task Modification/Creation/Deletion (the whole section) (current: via Event Logs / proposed: Yes)
Evidience: Screenshot
Below screenshot highlights Cortex XDR capabilities recording rpc calls related to schedule task modification, creation and deletion; RCP function names for above are SchRpcRegisterTask (create/modify) and SchRcpDelete (deletion)

Service Activity -> Service Creation/Modification (current: Via Event Logs/Proposed Yes)/Deletion (current: No/Proposed Yes)
Evidence: Screenshot
Below screenshot demonstrates capabilities to collect RPC Calls related to service creation, modification or deletion; RPC function names are RCreateServiceW (creation), RChangServiceConfigW (modify) and RDeleteService (delete)

Device Operation -> Virtual Disk Mount/USB Mount/USB Unmount (the whole section) (current: Partially Implemented / Proposed: Yes)
Evidence: Screenshot
Below screenshot shows capabilites to the agent without specific settings to collect mount and umount events. Documentation https://docs-cortex.paloaltonetworks.com/r/Cortex-XQL-Schema-Reference-Guide/Action-Actor provides additional details as of the field to track whether this is USB device or volume ones

Other Relevant Operations -> Group Policy Modification ( current: No/ Proposed: Via Event Logs)
Evidence: Documentation:
Link: https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-3.x-Documentation/Endpoint-data-collection?tocId=qGdNijq1x2qqjwetOGEhRQ
Cortex XDR collects event id 4662 which tracks modification on AD containers which Group Policies are

Other Relevant Operations -> Volume Shadow Copy Deletion (current: Pending Response / Proposed: Yes)
Evidence: Screenshot
Cortex XDR has detection mechanism through BIOC out-of-the box to detect deletion of Volume Shadow Copy. Below screenshot is an example of the result of that detection. As seen in the description, this detection is telemetry based.

Named Pipe Activity -> Pipe Connection (Current: No / Proposed: Yes)
Evidence: Documentation
Link: https://docs-cortex.paloaltonetworks.com/r/Cortex-XQL-Schema-Reference-Guide/Action-Actor
Cortex XDR collects Name Pipe Connection through actor_type where 2 means RemoteRpcNamedPipe

EDR SysOps -> Agent Start (current: No / Proposed: Yes)
Evidence: Screenshot
Below screenshots shows how the agent start event is collected (event_subtype = agent_status_agent_boot)

WMI Activity -> WmiEventConsumerToFilter /WMiEventConsumer/ WMI EventFilter ( the whole section) (current: via enabling telemetry / Proposed Yes)
Evidence: Screenshot
Cortex XDR collects RPC Calls for IWbemServices interface which tracks WMI activities

PowerShell Activity -> Script-Block activity (current: Via EventLogs/ Proposed: Yes)
Evidence : Screenshot
Below screenahot shows how Cortex XDR records powershell scripting capibilities without eventlogs but via .Net activity

Thank you for contributing to the EDR Telemetry Project! -->

[tsale]

Thanks for this PR @blb142857 , Please bear with us, as due to the number of requested changes, we need to validate everything through access to the product manually. I will update here on any progress or questions regarding the proposed changes.

[blb142857]

Hi @tsale,
I know you have been busy this last weeks but wondering when you'll be able to provide final review to that PR? Thanks

[tsale]

Hi @tsale, I know you have been busy this last weeks but wondering when you'll be able to provide final review to that PR? Thanks

Hi, thanks for the follow-up.

I’ve reviewed the submission and left comments on the PR where additional clarification or evidence is needed, specifically around URL visibility, named pipe activity, and WMI activity. Once those points are addressed with more explicit information or supporting evidence, I’ll be able to complete the final review.

Thanks for your patience.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[blb142857]

Hi @tsale,
I am seeing the conversations we had with regards to HID ( note: it requires device control to be activated not to be in block mode, it does not have to be blocking anything) and for shadowcopy ( inferred activity) but cannot see your comments on the URL part and the WMI part. Am I missing something here?

[tsale]

Hi @tsale,

I am seeing the conversations we had with regards to HID ( note: it requires device control to be activated not to be in block mode, it does not have to be blocking anything) and for shadowcopy ( inferred activity) but cannot see your comments on the URL part and the WMI part. Am I missing something here?

I’ve gone through the submission in detail and wanted to summarize my feedback here, as some inline comments don’t appear to be syncing properly.

First, on WMI activity (WmiEventFilter / WmiEventConsumer / WmiEventConsumerToFilter):
The evidence provided shows RPC calls to IWbemServices, which indicates generic WMI activity, but it does not demonstrate visibility into WMI event subscription artifacts themselves (filters, consumers, or bindings). There is no evidence of actionable details such as namespace (root\subscription), class names, instance names, filter queries, or consumer payloads. Based on the current evidence, this is not sufficient to mark the whole section as supported.

Second, on Named Pipe Activity:
The documentation reference to actor_type = RemoteRpcNamedPipe represents actor classification, not an explicit named pipe connection event. No telemetry was provided that shows a pipe name/path or a concrete pipe connection action. As such, this cannot be accepted as supported based on the current evidence.

Third, on Scheduled Task Activity:
After some additional RPC-focused research and testing (performed by the community, not by me), there are concerns that the RPC evidence provided may not be sufficient. The RPC ETW provider logs the interface and function name, but does not include details about the actual scheduled task object (for example task name, path, schedule, or XML content). The evidence submitted appears to only show that a scheduler RPC function was invoked, which is not very actionable beyond stating that “a scheduled task operation occurred”.
Unless additional context or parameters are captured, this likely needs to be reconsidered as Partially supported or No, rather than a full Yes.

Fourth, on Service Creation / Modification / Deletion:
A similar concern may apply here in principle. However, based on the screenshots, there does appear to be additional data present in ACTION_RPC_FUNC_INIT_CALL_FIELDS. It’s possible that service-related RPC telemetry is richer and more actionable, but the current evidence does not clearly demonstrate this. Clearer examples would help validate the extent of the data available.

Finally, a general clarification:
This project evaluates raw, observable telemetry, not detections or inferred conclusions. Evidence needs to demonstrate what concrete data is generated and available to an analyst. Detections, alerts, or high-level classifications are not considered sufficient proof of telemetry support on their own.

I’m happy to re-review these sections if more explicit telemetry evidence can be shared that demonstrates actionable fields and context.