Who Me Too'd this solution

P.S. My summary of this issue.

1. As @neelrohit mentioned here, these are decoy / honeypot files placed by Cortex XDR agent attempting to detect ransomware attacks. Given it was unclear whether Neel represented Palo Alto, i.e. that it was an official response from them, and the severity of the issue should the files have been malware, I was hesitant to declare an all-clear on this internally. I was also not having lots of luck getting a response from PAN Support.)
2. These appear to be links (rather than actual files), with the actual files residing in 'C:\ProgramData\Cyvera\Ransomware\1234567890123456789\' or a similar directory. (Which was perhaps the more definitive indication of the files not being malware.)
   • A way to check that it's a link in Powershell:
     
     Get-Item "<suspect filename>" | Format-List -Property *
     This should display a long list of properties including a line like this:
     Target : {C:\ProgramData\Cyvera\Ransomware\3196102225123340985\ZZZZZ2852017353.doc}
     ... which indicates that it's a link, and the actual file's path.
     
   • I have yet to figure out a way to check a filesystem for these links (count them, estimate their performance and size impact).
3. Cortex XDR did not flag anything when scanning the directories containing those links. Given the scan summary appeared to not include those files in total "files scanned" counts, and did not indicate any ransomware protection activity, this did not feel as trustworthy.
4. In extreme cases (like ours), these links are placed in every directory in the file system. Per @neelrohit's comments, this should only happen in "aggressive" ransomware protection mode - yet in our cases this seemed to be happening in "standard" mode as well.
5. We saw no indication of this activity (ransomware protection + creation of decoy / honeypot files and links) in Cortex XDR console or dashboard, and thus were unsure what's happening until we discovered the files were links pointing to hidden files in one of Cortex XDR directories. (See (2) above.)
6. In addition, we submitted one of those actual files to another AV vendor for analysis and got a "nothing bad found" response.
7. As of this morning, these links are no longer present in several directories where they were present before. Perhaps PAN Support cleaned them up through the dashboard. (Still waiting for a post-mortem.)
8. This may have been a case of a runaway process, bug, or otherwise unexpected behavior given all of the above.

What I am wishing for (that would have happened instead of what did):

• A clear indication of ransomware protection activity that's easily (enough) accessible to a local admin encountering the issue.
  • (Yes I realize a "local admin" could be someone maliciously accessing the system - and can still think of a way to securely present the necessary information to a legitimate first responder.)
• Vendor taking ownership of their product's behavior, whether expected or not - by responding to incidents quickly. (This did not happen here.)
• Vendor documenting this behavior, possible side effects, ways to stop or mitigate it should it have severe adverse impact on performance - in internally accessible documentation (e.g. customer portal) and quickly referencing it in similar incidents (did not happen here).
• A way to automate checking for similar behavior as well as its impact across the enterprise, answering questions such as:
  • How many honeypot / decoy files have been or are being placed by Cortex XDR in a given file system over a certain time?
  • What impact might this behavior have on disk response time, queue length and other system resources?

Hope this helps someone else having a similar issue!