- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
05-04-2026 03:20 PM
Hello Community,
I am working with Cortex XDR Pro and investigating the "Endpoint Blocked IP Addresses" section within the Action Center. I have a few specific questions regarding how entries are populated in this table and the best practices for targeted blocking:
Orchestration: How exactly are IPs added to this list? Does it only reflect automated response actions triggered by a playbook/prevention policy, or does it also include manual "Block IP" actions initiated by an analyst from an Incident or Causality view?
Granular Blocking: If I want to block a specific remote IP (e.g., an internal host performing a port scan) on a specific endpoint only, what is the recommended workflow if the "Block IP" option is not appearing in the Incident artifacts?
IOC/BIOC vs. Restriction Profiles: Is it possible to trigger a persistent block in this section by creating an IOC (providing the indicator, type, and severity)? Or should this be handled strictly through IP Lists within Restriction Profiles in the Endpoint Policy Management?
Action Persistence: According to documentation, these actions expire after 90 days. If a block needs to be permanent, should it be moved from the Action Center to a Global Block List?
I recently encountered a "Suspicious Port Scan" alert from an internal host (XDR Analytics source). While the alert was generated, the IP was not automatically blocked. I am trying to determine the most efficient way to manually push that IP to the blocked list for the targeted server.
Any insights on the internal logic Cortex uses to populate this specific view would be greatly appreciated.
05-05-2026 06:54 AM
Hello @QuestionAb ,
Greetings for the day.
Based on the internal sources and support resources for Cortex XDR, here is a detailed breakdown of the internal logic for the "Endpoint Blocked IP Addresses" section and the recommended workflows for IP blocking.
The Endpoint Blocked IP Addresses tab within the Action Center is primarily designed to reflect automated response actions performed by the Cortex XDR agent.
If the "Block IP" option is not available (as it is not a standard manual artifact response for IP addresses) and you need to block a specific internal host (e.g., a port scanner) on a specific server, the recommended workflow is to use Host Firewall Profiles:
The "Suspicious Port Scan" alert from XDR Analytics is a server-side detection based on ingested logs. The automated blocking mechanism ("Respond to Malicious Causality Chains") only triggers when the agent's local BTP/Malware engine identifies a high-confidence prevention event in real-time on the endpoint. Since Analytics alerts are generated after log processing on the server, they do not automatically trigger the agent-side WFP block rules.
You can verify if an IP is currently blocked on an endpoint by using the cytool utility:
"C:\Program Files\Palo Alto Networks\Traps\cytool" unblock_remote_ip operation list
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
05-05-2026 06:54 AM
Hello @QuestionAb ,
Greetings for the day.
Based on the internal sources and support resources for Cortex XDR, here is a detailed breakdown of the internal logic for the "Endpoint Blocked IP Addresses" section and the recommended workflows for IP blocking.
The Endpoint Blocked IP Addresses tab within the Action Center is primarily designed to reflect automated response actions performed by the Cortex XDR agent.
If the "Block IP" option is not available (as it is not a standard manual artifact response for IP addresses) and you need to block a specific internal host (e.g., a port scanner) on a specific server, the recommended workflow is to use Host Firewall Profiles:
The "Suspicious Port Scan" alert from XDR Analytics is a server-side detection based on ingested logs. The automated blocking mechanism ("Respond to Malicious Causality Chains") only triggers when the agent's local BTP/Malware engine identifies a high-confidence prevention event in real-time on the endpoint. Since Analytics alerts are generated after log processing on the server, they do not automatically trigger the agent-side WFP block rules.
You can verify if an IP is currently blocked on an endpoint by using the cytool utility:
"C:\Program Files\Palo Alto Networks\Traps\cytool" unblock_remote_ip operation list
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
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!

