Cortex XDR - False positive - Cloud2Model Manager 1.005

[eproca]

hi,

Some of the users of Cloud2Model are resporting that Cortex XDR is blocking the installer "Cloud2Model Manager 1.005 x64 setup.exe" with this Cortex XDR code: c0400055. This is a legitimate application and the installer is signed with a EV code certificate. You can check the instaler here:

https://download.cloud2model.com/manager

Please check this issue ASAP. I am very interested in knowing the reasons that trigger to block the file.

Many thanks in advance.

[gjenkins]

Hi @eproca ,

From what I can tell, you may be encountering an issue where Local Analysis has determined that your sanctioned software is malware and is blocking it due to policy configuration. To override the local analysis verdict and permit this software to run immediately, you can apply the hash for the file in the Allow List for Cortex XDR using the following instructions.

To understand why your file was blocked, I would recommend opening the Hash View to see the information collected by Cortex XDR in terms of the threat intelligence and the incidents related to the hash. You can access the Hash View by clicking the circle icon () on the top-right of your screen, pasting the hash into the search bar, and clicking, "Open Hash View of..." There you will find more information regarding the hash and the verdict provided.

Please let me know how this goes when you have the opportunity.

[eproca]

hi @gjenkins ,

Thanks for your feedback. I am the application developer but not the Cortex XDR user. I dont have any direct access to the Action Center of Cortex XDR or possibility to check the Hash View. Anyway I will pass the information to the actual Cortex XDR users.

Is there any way to "white list" a file globally for Cortex XDR? I mean without having to be an actual user of Cortex XDR. Some antivirus have proccedures and protocols for this kind of situations.

Many thanks in advance for your support

[fmoixsante]

Hi @eproca,

As you mention, I would get in touch with your XDR admin and refer him to the following links.

•   https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/endpoint-security/endpoint-...
  • Here you can add applications path and name to the Allow list directly in the Malware profile. By doing this, you can use the wildcard (*) and future-proof the tuning
    
    • c:\folder_a\folder_b\folder_v1.2.3\application_v1.2.3.exe could turn to c:\folder_a\folder_b\folder_v*.*.*\application_v*.*.*.exe
    • Something like the above will make sure that current and future same application versions are allowed by the XDR agent
    • NOTE, adding anything to the allow list in the Malware profile is like poking a tiny whole in the security of the XDR agent, so please be as precise as possible and do not overuse the wildcard (*)

You also mentioned that the application you want to allow is also digitally signed. You can also add the signature to the Allow List Signer in the Malware Profile,

•  https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/endpoint-security/endpoint-....

[gjenkins]

Hi,

Passing the information along to the Cortex XDR administrators for your instance is the best next step in this case. Thank you for forwarding it. Once they have applied the hash to the allow list, it will apply to all endpoints within your environment.

You can add to the allow list for your environment globally by using the instructions above or watching the following video.

XDR Pro + Prevent

Managed File Execution

As for a true global verdict via Wildfire submission, the best way to submit is by executing the file on a device with Cortex XDR. Once executed, Wildfire will receive a copy submitted from that endpoint and provide its verdict within 24 hours. That verdict is distributed globally across all tenants.

[eproca]

Thanks @fmoixsante  for the possible solutions and thanks again @gjenkins for the support.

One question: the application is signed with an EV code certificate. @fmoixsante explains that it can be added to an Allow List Signer in the Malware Profile. Will this help to avoid false positives in future files signed with the same certificate?  Honestly, I am not so amused with the idea that each new future installer will need some kind of special managment by the Cortex XDR administrators.

Thanks in advence for the support.

[gjenkins]

That's a great question, @eproca .

Adding your signers to your allow list will exclude signed "executable files, macros, or DLL files on Windows endpoints, Mach-O files or DMG files on Mac endpoints, ELF files on Linux endpoints, or APK files on Android endpoints" from the malware examination. It will still be subject to scrutiny by other protective modules such as Behavior Threat Protection, Child Process Protection, and any other applicable module given the activities observed.

We are here to support if a false-positive is found. If it does happen, please feel free to have the XDR administrators submit a verdict change request or open a case with Support to investigate further.

[JHugget]

Hi, 

   I have an application that keeps getting blocked because the hash keeps changing each time it is downloaded.  It is digitally signed by the publisher and I was wondering if you had instructions on allowing the program based off the signature instead of the installation path.

[gjenkins]

Hi @JHugget ,

The instructions you're asking for are here, as referenced by @fmoixsante earlier in the thread. This will help exempt your file from scanning due to the changing hash.

[eproca]

Thanks again for the support @gjenkins.

I have been told that after one day the same installer file did not trigger any warning from Cortex XDR any more. And without any action from the administrators of Cortex XDR. Maybe some action in the paloaltoN side?. Anyway thanks again for the support.

[gjenkins]

Hi @eproca, 

That makes sense as WildFire likely produced and distributed a verdict for the file within that time. If you have other questions in the future regarding the process, please feel free to reach out.

[fmoixsante]

Hi @eproca,

The current Wildfire flow for unknown applications, and by unknown I mean not known to WildFire, is as follows

• Executable/DLL is executed,
  1. XDR agent Local Analysis engine will check its Wildfire-cache file for the hash sha256 value, and block or allow accordingly
  2. If hash is not in the file, the XDR agent will communicate with the XDR service for the hash sha256 value. If hash is known by the service, the XDR agent will download the info to the wildfire-cache file and allow/block as per the verdict
  3. If the XDR service does not know the hash, it will communicate with the Wildfire cloud and follow point 2 if known
  4. If the hash is not known in Wildfire, the XDR agent will upload the unknown executable to the Wildfire cloud for it to be dynamically analyzed in isolation. This process could take 10-20 minutes depending on file size, upload link speed, etc.

In your case, the installer that was being blocked uploaded to Wildfire, and it was scored as benign allowing it to execute in your system. To clarify, every executable has a unique hash value. If the application gets an update, this new version of the installer will get another unique hash value.

You could do 3 things, 

1. Add the digital signature Common name to the Trusted Signer Allow list in the Malware profile, or
2. Add the path and name of the file to the Allow list of the Malware profile, or
3. Wait for the whole wildfire flow to follow its course and after 10-20 minutes, you will get a verdict that could be Benign, Malware or Grayware
4. if Benign leave as is
   • If Malware, and if you block Grayware, do points 1 or 2, and as mentioned by @gjenkins, report the verdict as incorrect. This report will be reviewed by our Anti-malware research team and flip the verdict in WF if they agree with you.

I would recommend that if the application is legit and needed for your every day work, to follow step 1 or 2, to avoid this kind of situations in the future.