BleepingComputer.com Says Disable Shadow Volume Copies Now!

http://www.bleepingcomputer.com/news/security/why-everyone-should-disable-vssadmin-exe-now/

 

That may work (for now), but it's extremely stupid and shortsighted IMO. Any C/C++ based malware could use VSS API calls. Or even something written in Python or Ruby. Or a malware dropper could just bundle its own copy of vssadmin.

Keep offline backups instead. And don't use an admin account for day-to-day stuff. The former is a small effort, the latter is absolutely trivial.

Edit: I'm struggling for an analogy to describe this security theater. The closest I can come is something like, "OMG, the 'rm' command lets you delete the whole system if run as root! You should remove /bin/rm right now!"

It's clear, simple, and completely wrong.

 

Also the BleepingComputer script needs to be modified for x64 systems. For every instance of %WinDir%\system32\vssadmin.exe, you will have to add %WinDir%\SysWow64\vssadmin.exe since I have seen instances of CryptoLocker using the vssadmin.exe instance in SysWow64 directory.

Actually I monitor the following with an Eset HIPS rule. Note that the DOS pipe symbol "|" is the only way I can enter command line arguments in that HIPS.

C:\Windows\syswow64\vssadmin.exe|Delete|Shadows|/All|/Quiet
C:\Windows\syswow64\vssadmin.exe|vssadmin.exe|Delete|Shadows|/All|/Quiet
C:\Windows\System32\vssadmin.exe|Delete|Shadows|/All|/Quiet
C:\Windows\System32\vssadmin.exe|vssadmin.exe|Delete|Shadows|/All|/Quiet
C:\Windows\System32\bcdedit.exe|bcdedit|/set|{default}|recoveryenabled|No
C:\Windows\System32\bcdedit.exe|bcdedit|/set|{default}|bootstatuspolicy|ignoreallfailures

 

VSSAdmin.exe comes blacklisted by default in Bouncer's policy file. Bouncer's developer has blacklisted a lot of vulnerable executables that other developers around Wilders has not. bitsadmin.exe is another one in which the developer has blacklisted. bitsadmin.exe can be used to gain full access to one's machine. It's worth reading about in his blog. http://excubits.com/content/en/news_001.html

Edited 11/8 @ 9:29

 

IMO the name of a thread is misleading. Shadow volume copies should not be disabled, only Vssadmin, a tool to manage those copies. Does anybody know if disabling this tool (let's say using SRP rules) affects how shadow volume copies are created? I think that it doesn't but it would be nice to hear it from someone who tested it (I don't want to break Macrium...).

 

According to BleepingComputer, the only software affected is:

When testing this method, I have not found any functionality lost within Windows and the only program that I know of that no longer operates when it is renamed is Shadow Explorer.​

 

Appears bitsadmin.exe is not even used anymore by WIN 7+ OS's:

BITSADMIN is deprecated in Windows 7 and 2008 R2, it is superseded by the new PowerShell BITS cmdlets.
ref: http://ss64.com/nt/bitsadmin.html
​

Which means that unless Bouncer is monitoring all Powershell processing, it could execute. I do wonder however if bitsadmin.exe is used in the WIN 10 upgrade processing?

The issue however is if the malware has access to system32 or SysWow64 directories and can escalate privledges, it is pretty much game over.

 

Another FYI from Mr. Bleeping himself which is applicable to users of SRP and anti-execs that store their policies in the registry:

Grinler - 1 day ago

• 
  

Though, I agree CryptoPrevent has become an essential tool these days, I still recommend you rename vssadmin.exe altogether. Its a very niche tool that that vast majority will never use but has a high risk to it.

Also, if a malware executes from a location that SRPs do not block, that malware could easily remove those SRPs by editing the registry. Safer, for this particular exec, to just rename it.​

 

Thanks for answers about vssadmin.exe. I've added both executables (from System32 and Syswow64) to SRP blacklist.
@Cutting_Edgetech : I've checked that blog but couldn't find any info about bitsadmin.exe. Do you have any other reference? Thnx.

 

The bitsadmin entry should still be in there. It's an older entry.

 

Wouldn't it be the same as an exploit using Powershell though? Blocking the resources used by the exploit will limit what the exploit is capable of doing.

 

Btw.. my blacklist of vulnerable processes is so long an exploit would have a hard time doing anything on my machine. I've went through my System32, and SysWOW64 folder with a fine tooth comb. I think it would be hard for an exploit to bypass Bouncer, and launch a blacklisted executable. I'm not saying it can't be done, but I would love to see it.

 

Powershell can be run from a C# or .Net program.

-EDIT-

You can host a powershell runtime inside a .net application using the System.Management.Automation dll. This BTW is the actual "guts" of Powershell. Powershell.exe is just an interface to System.Management.Automation dll

 

Would adding it to AppGuard do the trick?

 

I see 4 exes:

"C:\Windows\WinSxS\amd64_microsoft-windows-bits-bitsadmin_31bf3856ad364e35_6.3.9600.17415_none_3e1c8be8e0297efa\bitsadmin.exe"
"C:\Windows\SysWOW64\bitsadmin.exe"
"C:\Windows\WinSxS\x86_microsoft-windows-bits-bitsadmin_31bf3856ad364e35_6.3.9600.17415_none_e1fdf06527cc0dc4\bitsadmin.exe"
"C:\Windows\System32\bitsadmin.exe"

"C:\Windows\SysWOW64\vssadmin.exe"
"C:\Windows\WinSxS\x86_microsoft-windows-vssadmin_31bf3856ad364e35_6.3.9600.17415_none_5969b4d34d03aa1f\vssadmin.exe"
"C:\Windows\System32\vssadmin.exe"
"C:\Windows\WinSxS\amd64_microsoft-windows-vssadmin_31bf3856ad364e35_6.3.9600.17415_none_b588505705611b55\vssadmin.exe"

Which one or all of them to add into vulnerable processes in ERP?

 

NVT ERP, and AppGuard use two different methods. If you are using ERP then ERP will alert you if it attempts to run if you add it to the Vulnerable Process List. ERP will give you the option to block it from running with an alert. AppGuard will allow it to run with limited rights if you add it to the Guarded Apps List, but you can't block it from running. The malware would most likely execute from the user-space so AG would block it from running before it could attempt to use vssadmin.exe

 

Will adding vssadmin.exe to ERP Vulnerable Processes affect normal run System Restore.
And also add bcdedit.exe ....?
I find vssadmin.exe with System32 and SysWOW and bcdedit.exe with System32 #3

Edit: added two vssadmin.exe + bcdedit.exe
Manual create restore point works.
I've don't use System Restore.....but, still create for some Windows Update.

 

Will adding to ERP Vulnerable Processes affect normal run System Restore.

 

According to replies on BleepingComputer it shouldn't. It seems that System Restore and other imaging software doesn't use it. I wonder if Disk cleanup - Remove old System restore points and Shadow copies option uses this tool to perform maintenance?

 

Yeah, I posted Edit here #18
I had not added to Vulnerable Processes before so, I figured lets see what happens.

 

No system restore, just Macrium.