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?
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:
Hope this helps.
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.
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:
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.
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.
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!