topic Re: Another week, another BTP quirk: Behavioral threat detected (rule: sync.enable_safemode_on_next_reboot) spawned from VEEAM in Cortex XDR Discussions

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

RobertoPastorino — Wed, 17 Aug 2022 07:44:24 GMT

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.

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

RobertoPastorino — Wed, 17 Aug 2022 09:14:07 GMT

Our observed CGO

C:\Windows\system32\svchost.exe -k netsvcs -p -s Winmgmt
C:\Windows\system32\svchost.exe -k netsvcs
C:\\Program Files (x86)\\Veeam\\Backup Transport\\VeeamTransportSvc.exe\""

All trying to modify a specific reg key:

key_name": "bcd00000000\\objects\\{d80ed0e8-d6da-11e7-b27f-ab3a45175c5d}\\elements\\25000080"

"value": "base64: AgAAAAAAAAA="

AgAAAAAAAA= it's a NULL sledge , effectively impeding the boot in safe mode.
(valid values are: 0 = Minimal 1 = Network 2 = DsRepair)

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

DavidStevens — Wed, 17 Aug 2022 11:35:46 GMT

We need to get this solved, it's blocking the jobs that use application aware. Identical error to yours, i'm just not sure how to make an exception to stop veeam from blocking it. first time i've had to make an exception in cortex xdr.

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

parkerjr2 — Wed, 17 Aug 2022 12:11:40 GMT

We are also seeing this problem all domain controllers this morning. I may whitelist and wait for a response from PA on whether a new content update will allow me to undo a whitelist entry.

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

Retired Member — Wed, 17 Aug 2022 12:56:09 GMT

Our Veeam backups on our DCs are also broken as of this morning. The only way I see to whitelist this is by adding the hash for SVCHOST.exe... seems too risky at this point in time. I'll create a support ticket as well, but please do post your responses from support.

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

derekmayberry — Wed, 17 Aug 2022 13:51:48 GMT

Same issue for me this morning. Had weird errors I'd never seen in the Veeam backup reports and I am glad to see this thread. Hopefully a new BTP update will release today to resolve. We obviously can't whitlelist svchost.exe. I opened a ticket just now and will reply with the response.

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

afurze — Wed, 17 Aug 2022 13:53:53 GMT

Hello everyone,

We have received a number of TAC cases regarding this issue and our engineering team is aware and working to address.

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

ianatgrafton — Wed, 17 Aug 2022 14:10:00 GMT

It does only appear to be affecting application aware backups

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

Brad_Lape — Wed, 17 Aug 2022 14:40:23 GMT

We have a support case currently opened with Palo for this issue and their suggestion was to whitelist this activity, but we have done that and just tried to kick off backups of our Domain Controllers and it is failing now. Seems that the registry and BCD editing that XDR blocked that VEEAM was trying to make yesterday evening, isn't something that VEEAM writes again (or just assumes that the changes took when XDR prevented them from happening) upon re-try of the backup jobs?

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

jturner_storm7 — Wed, 17 Aug 2022 15:06:42 GMT

I saw the same behavior this morning. I didn't realize at the time that Cortex was catching it, so I was troubleshooting otherwise. I ended up re-registering VSS components twice and that seemed to resolve my issues.

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

ebourdajorge — Wed, 17 Aug 2022 15:26:29 GMT

we have the same problem... i waiting for response for support pls!

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

Brad_Lape — Wed, 17 Aug 2022 15:38:14 GMT

Are the VSS components you are talking about, this: https://www.veeam.com/kb2041 ?

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

jturner_storm7 — Wed, 17 Aug 2022 15:43:28 GMT

Here's one script that I ran:
net stop "System Event Notification Service" /y
net stop "Background Intelligent Transfer Service" /y
net stop "COM+ Event System" /y
net stop "Microsoft Software Shadow Copy Provider" /y
net stop "Volume Shadow Copy" /y
cd /d %windir%\system32
net stop vss
net stop swprv
regsvr32 /s ATL.DLL
regsvr32 /s comsvcs.DLL
regsvr32 /s credui.DLL
regsvr32 /s CRYPTNET.DLL
regsvr32 /s CRYPTUI.DLL
regsvr32 /s dhcpqec.DLL
regsvr32 /s dssenh.DLL
regsvr32 /s eapqec.DLL
regsvr32 /s esscli.DLL
regsvr32 /s FastProx.DLL
regsvr32 /s FirewallAPI.DLL
regsvr32 /s kmsvc.DLL
regsvr32 /s lsmproxy.DLL
regsvr32 /s MSCTF.DLL
regsvr32 /s msi.DLL
regsvr32 /s msxml3.DLL
regsvr32 /s ncprov.DLL
regsvr32 /s ole32.DLL
regsvr32 /s OLEACC.DLL
regsvr32 /s OLEAUT32.DLL
regsvr32 /s PROPSYS.DLL
regsvr32 /s QAgent.DLL
regsvr32 /s qagentrt.DLL
regsvr32 /s QUtil.DLL
regsvr32 /s raschap.DLL
regsvr32 /s RASQEC.DLL
regsvr32 /s rastls.DLL
regsvr32 /s repdrvfs.DLL
regsvr32 /s RPCRT4.DLL
regsvr32 /s rsaenh.DLL
regsvr32 /s SHELL32.DLL
regsvr32 /s shsvcs.DLL
regsvr32 /s /i swprv.DLL
regsvr32 /s tschannel.DLL
regsvr32 /s USERENV.DLL
regsvr32 /s vss_ps.DLL
regsvr32 /s wbemcons.DLL
regsvr32 /s wbemcore.DLL
regsvr32 /s wbemess.DLL
regsvr32 /s wbemsvc.DLL
regsvr32 /s WINHTTP.DLL
regsvr32 /s WINTRUST.DLL
regsvr32 /s wmiprvsd.DLL
regsvr32 /s wmisvc.DLL
regsvr32 /s wmiutils.DLL
regsvr32 /s wuaueng.DLL
sfc /SCANFILE=%windir%\system32\catsrv.DLL
sfc /SCANFILE=%windir%\system32\catsrvut.DLL
sfc /SCANFILE=%windir%\system32\CLBCatQ.DLL
net start "COM+ Event System"

And here is the other:

cd /d %windir%\system32
net stop vss
net stop swprv
regsvr32 /s ole32.dll
regsvr32 /s oleaut32.dll
regsvr32 /s vss_ps.dll
vssvc /register
regsvr32 /s /i swprv.dll
regsvr32 /s /i eventcls.dll
regsvr32 /s es.dll
regsvr32 /s stdprov.dll
regsvr32 /s vssui.dll
regsvr32 /s msxml.dll
regsvr32 /s msxml3.dll
regsvr32 /s msxml4.dll
vssvc /register
net start swprv
net start vss

Validate that all necessary services on your DC are running when finished. I had to restart my DHCP server service, which was stopped in the process.

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

Brad_Lape — Wed, 17 Aug 2022 15:50:05 GMT

Thank you, J Turner, do all those commands fix this issue then: https://www.veeam.com/kb1697 ?

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

jturner_storm7 — Wed, 17 Aug 2022 15:58:33 GMT

I can tell you that it fixed my issues, which were identical to what was in the original post. I had 5 events in cortex appear for each server, and veeam jobs were failing until I went through and ran these. Also to note I did update my servers with latest patches as well.

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

parkerjr2 — Wed, 17 Aug 2022 16:13:48 GMT

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

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

jturner_storm7 — Wed, 17 Aug 2022 16:15:33 GMT

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

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

CSGandD — Wed, 17 Aug 2022 16:45:03 GMT

Hello!

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

Right click the alert
Click "Manage Alert"
Click "Create Alert Exception"
Check the options "CGO Process Path" and then "CGO Command Arguments"
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:

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/

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

jturner_storm7 — Wed, 17 Aug 2022 16:21:15 GMT

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

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

CSGandD — Wed, 17 Aug 2022 16:30:28 GMT

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!