Local Analysis Malware and WildFire Malware Alerts

[clairamore]

Can someone explain the Local Analysis Malware and WildFire Malware alerts. The WildFire alerts seem straightforward for a file that it deems malware. On the other hand, the local analysis malware alerts trigger for a bunch of files but in the alert it has a wildfire report and verdict that says benign. 
Moving into suppressing these alerts, the module in the alert is listed as Local File Analysis and Wildfire. When adding the file to an exception, neither of those are a module choice to whitelist from. Under the assumption it was scanning based on the alert, I have tried adding it to the endpoint scanning and the PE and DLL examination modules but the alerts still trigger. Any help or explanation would be appreciated!

[susekar]

Hello @clairamore ,

Greetings for the day.

Are you referring to the Local Analysis detections for the Microsoft binary StoreDesktopExtension.exe? If so, please find the responses below. If your question is more general, kindly let me know.

Summary:

Local Analysis Module is generating False Positive (FP) issues/alerts on Windows endpoints for the Microsoft binary StoreDesktopExtension.exe. The verdict has been validated by the research team and updated in Wildfire.

Symptom:

Customers have reported multiple alerts related to the unsigned Microsoft binary that has been distributed at least since January 2026. 

Indicators:

• StoreDesktopExtension.exe
• SHA256 - ADEE0EC3096B4778F6A5951647371F3FF67B8FA0D96C37FB795BCFCFE0E1154E.

Cause:

The root cause of the recurring False Positive (FP) is the detection by the Local Analysis module after it is unable to verify the WildFire verdict.

The main issue to investigate is why the endpoint is not reaching the WildFire cloud. 

The following reasons have been observed so far due to the customer environment:

• Access from the endpoint to the WildFire cloud is blocked in the customer firewall
• Deep packet inspection (DPI) is opening the SSL connection, forcing the agent to drop the connection to WildFire
• A combination of DPI plus Certificate Enforcement setting enabled in the Agent Settings policy

Resolution

There are currently two approaches to resolve this issue. 

-One is temporary, and will work for this specific file as long as the hash doesn't change for any reason. 

-The permanent fix is to ensure the XDR Agent can reach the WildFire cloud in order to obtain the latest verdicts.

Both require an agent check-in as a final step to refresh the local databases. 

The temporary workaround for this specific hash is to add it to the Allow List:

1. Open the XSIAM Tenant UI
2. Navigate to Investigation & Response → Action Center
3. Press the +New Action button
4. Select the Add to allow list action in the list.
5. Add the Hash ADEE0EC3096B4778F6A5951647371F3FF67B8FA0D96C37FB795BCFCFE0E1154 
6. Add a comment that will help identify this change
7. Follow through the next pages to apply the workaround

-------------------------------------------------------

For a permanent fix, the root cause of the XDR Agent not reaching WildFire must be investigated and corrected.

1. Ensure the endpoints are allowed to reach the resources published in https://docs-cortex.paloaltonetworks.com/r/Cortex-XSIAM/Cortex-XSIAM-Documentation/Enable-access-to-...
2. Specifically, ensure the following FQDN can be reached on port TCP/443: cc-<xsiam-tenant>.traps.paloaltonetworks.com  
3. Review the Tech Support File, specifically the traps.d log and look for issues with the verdict FQDN from step 2.
   
   
   

   If you feel this has answered your query, please let us know by clicking like and on "mark this as a Solution".

   Happy New year!!

   Thanks & Regards,
   S. Subashkar Sekar