Another week, another BTP quirk: Behavioral threat detected (rule: sync.enable_safemode_on_next_reboot) spawned from VEEAM

[RobertoPastorino]

We are observing VEEAM VeeamTransportSvc.exe being blocked by BTP and, thus, preventing backups from being started.

We are working on a temporary fix excluding path and cgo and the likes but this is the second week in a row that content updates are screwing, this time impacting operations.

Already filled a support case.

BR

[parkerjr2]

My DC backups usually take less than 2 minutes each so I have contemplated trying to disable the tool for that time and run the backup.

"c:\program files\palo alto networks\traps\cytool.exe" protect disable

then after the backup
"c:\program files\palo alto networks\traps\cytool.exe" protect enable

[jturner_storm7]

That should work according to what I've read as a stop gap until cortex tram figures out what caused the false trigger. 

[CSGandD]

Hello!

The best way to prevent this behavior from being blocked in my opinion is to create an alert exception:

1. Right click the alert
2. Click "Manage Alert"
3. Click "Create Alert Exception"
   
4. Check the options "CGO Process Path" and then "CGO Command Arguments"
   
5. Select the desired scope and then click "Create"

Please note that this Behavioral Threat is an attempt by Palo Alto to detect the exploitation of recently released boot vulnerabilities:

• https://www.bleepingcomputer.com/news/security/microsoft-blocks-uefi-bootloaders-enabling-windows-se...
• Check if your bootloaders are vulnerable to this!

Edit: This detection may more specifically relate to detecting boot configuration changes used by ransomware groups, that said, I can imagine both techniques being used in tandem:

• https://www.binarydefense.com/detecting-ransomwares-stealthy-boot-configuration-edits/

[jturner_storm7]

The only downside to this is that there would now be an exception and it could be exploited by a legit threat.

[CSGandD]

You are absolutely correct. Ideally, if the block is not impacting, it shouldn't be removed.

• If it is impacting, the vulnerabilities should be mitigated prior to removing the block if possible
• If they cannot be mitigated without removing the block:
  • Disconnect the host from the network
  • Remove the block
  • Apply the available patch
• And finally, if the block needs to be removed AND host cannot be disconnected from the network due to essential services being impacted:
  • Cross your fingers, close your eyes, remove the block and then apply the patch if this is within your risk tolerances, lol

Best of luck to all, hopefully more targeted indicators of the actual exploits are identified soon!

[derekmayberry]

Do we know for sure that even if the referenced windows update in those articles (below) gets installed, that the Cortex BTP no longer affects the system?  If it still does affect things, then we need a better answer than to whitelist a critical component of Windows that plenty of malware targets.  

Isn't there a way to do a BTP exception within BTP somehow vs global exception of svchost.exe?

KB5012170 

[ChrisPeters]

I ran these scripts and then was able to backup our domain controllers again. I rebooted one just to see what happened and the Veeam error came back again after the reboot.

[parkerjr2]

I tried disabling Cortex on a DC via cytool as I mentioned earlier but the backups still failed.

[jturner_storm7]

Interesting. Well hopefully this will help support narrow in on the root cause!

[ChrisPeters]

For real! If you run the scripts again after a reboot you will be to run backups again.

[RobertoPastorino]

Ok so the workaround is to re-register the vss components and don't reboot, backups should run as expected.

For the resolution, I think that a quick workaround could be check the value to which the reg key is setted, if is not one that cause a safeboot, raise an alert but not block the execution.

Post DEFCON shenanigans at it's best, seems to me..

[parkerjr2]

On a hunch, rather than re-registering all the files, I just plucked out the service names and did a stop/start on each of them. 
Next I tried the backup and it worked. Having said that, it looks like the regsvr32 portion of this is not required.
Also, the stop/start didn't work automatically on all of them. I ran them one at a time and some said they weren't even running. Some also stopped other services. After trying to stop/start them all, I sorted the services by startup type and manually started any that weren't restarted from my stop/start. After I did that, I tried the backup and success.

[parkerjr2]

Here's what got my backup working. I added the necessary services here that the original script was not restarting.

net stop "System Event Notification Service" /y
net start "System Event Notification Service"
net stop "Background Intelligent Transfer Service" /y
net start "Background Intelligent Transfer Service"
net stop "COM+ Event System" /y
net start "COM+ Event System"
net stop "Microsoft Software Shadow Copy Provider" /y
net start "Microsoft Software Shadow Copy Provider"
net stop "Volume Shadow Copy"
net start "Volume Shadow Copy"

net start "System Event Notification Service"
net start "DFS Replication"

[RobertoPastorino]

Got a ticket reply this early morning, FYI for everyone that had not opened a ticket

Comment: Hi Roberto,

We have released a KB article noting on this issue with Veeam Backup, for your reference,

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000wlJGC

The Eng Team has deployed the fix in CU650-11590, please make sure affected endpoints are updated with this CU to avoid the prevention of Veeam Backup process.

We apologise for any inconvenience caused.

Regards,

Note: the kb article, at this moment, leads me to a salesforce error page

[RFeyertag]

Yes, I have the same problem with the salesforce error page.