Blocking of IOC in cortex XDR

Showing results for 
Show  only  | Search instead for 
Did you mean: 
Please sign in to see details of an important advisory in our Customer Advisories area.

Blocking of IOC in cortex XDR

L3 Networker

How can IOCs be blocked on XDR so we don't observe alerts or incidents related to it at all? 

When putting the hash of the IOC in the block list through the action centre it still triggers incidents and alerts.

Is there any other way other than using alert exclusion to not see alerts at all related to the blocked IOC?




L5 Sessionator

Hi @Shashanksinha , 


Thank you for writing to live community!


IOC rules in XDR are detect only. However, it depends on the actions you would want to take to prevent those indicators from acting into the environment using endpoint security solution. I have suggestions listed below for indicators:

  1. Hash: Add the hashes to the block list and remove it from IOC rules, it should not trigger noises as incident for you and only low severity alerts as Administrative Hash Exception when the hash is executed on endpoints with the Cortex agent.
  2. IP: For IP, Cortex XDR host firewalls can be leveraged for performing network connection blocking or should be implemented on firewalls for blocking. Direct push to firewalls for threat feed IP or malicious/risky IPs can also be done by configuring EDLs from Cortex XDR on the firewalls
  3. Domain: Cortex XDR cannot do domain blocking and hence this should be implemented on firewalls only.
  4. filename: You can use retsriction profiles to set up block list for files with the filename. 
  5. Fullpath: Same as 4.

Hope this helps.



Hello @neelrohit 

Thank you for the response to the above query.

Had a few more questions, 

Is there any way  to block events for added IOCs by Cortex  XDR?

Is there any limit for hashes added in blocklist and

Also, what all hash types can be added in the block list?

Will there be any incident/alert for hashes added in Block list?

How should we provide exceptions for AV folders of other solutions or folders of other legitimate solutions where we do not want Cortex XDR to scan files or take any action?
Also,what are the recommended best practices while providing exception to folders?



Hi @Shashanksinha ,


to answer your question, as I just stated above, the added IOCs can be added in the format as in the previous texts. There are no limits for hashes to be added to the block list and Cortex XDR detects SHA256 hashes for Action response. As just mentioned above, if there are hashes added to the block list and that SHA256 executable is executed/scanned by Cortex XDR, we will have low severity alerts by the name "Administrative Hash Exception" generated for the same( no Incidents).


To answer exclusions and exceptions is a very broad question as there are many circumstances and mechanisms to do so(file path allow list or hash allow list). For scanning exclusions, you can add the file paths to the scanning allow list under the Malware Profile.

Thank you for the response. 

Can you please help with 

How should we provide exceptions for AV(anti-virus) folders of other solutions or other legitimate solutions where we do not want Cortex XDR to scan files or take action?


Hi @Shashanksinha , 


As I just stated above, for scanning allow list, you should add the file paths to the allow list under the malware scan category to prevent any scanning on those folders and sub folders.


Cortex XDR examination is divided into two phases: 

1. Pre-execution 

2. Post Execution.


for Pre-execution(where general wildfire malware/local analysis/ digital signer restrictions) we can either create hash allow list or file path allow list. For post-execution modules, which are related to BTP, ransomware etc, you should have file path allow list under the BTP category as well.


If you have ideas to completely disable all protection from Cortex XDR and nothing as a solution should be detected or prevented on those executables, please consider using process exceptions and check the modules you want to disable on Cortex XDR. 


Please consider, this should be regulated and tested before being performed and should used case scenario basis. Palo Alto Networks will not speculate and support for exploitation/malicious activities performed using the processes added to exceptions if the agent protection capabilities are disabled on those known areas.




L3 Networker

Hello @neelrohit 

Thanks for the responses . 

Do you have idea about the below :-

 Received one advisory from Palo Alto titled "Cortex XDR Agent Coverage for Microsoft Exchange Server Remote Code Execution Vulnerability Detection and Protection "

Needed some clarity on this advisory.

Like a point was mentioned
To ensure you are receiving alerts and monitoring any exploitation attempts:
• Restart Microsoft Internet Information Services (IIS) using the command: “iisreset”

Is it mandatory to follow all the steps mentioned in the advisory and will there be any protection against exploitation attempts if these steps are not done?

"iisreset" reset on the servers.

Performing "iisreset" will cause downtime on the server .
 Is it compulsory to perform "iisreset" on the exchange servers in order to receive alerts for exploitation attempts? Any workaround for this?





HI @Shashanksinha ,


I would request you to kindly post a new question in the discussion for this issue as this is not related to the original header and mark this discussion as solution accepted if you find that your initial query was answered. 

We will answer the same on the new discussion. 

Quick answer to your question regarding the step is yes, the service needs to be reset for the protection to work.

  • 7 replies
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!