Ransomware - File and Folder permissions

We've had issue with ransomware.  Interesting how it knew to go to our NAS and delete all the folders with the local backups when there was no mapped drive to follow.  Seemed to us they know how to analyze Shadowprotects config (and probably many others) and knew exactly where to go.    Since there was no mapped drive to that device we mistakingly thought it was safe.  Well, live and learn.  

I want to harden these folders against access by any account except the one ShadowProtect is using that way if they compromise a user account they have no access.  How can I determine what account it is using to manage those files?  It's using the Local System Account for the service, can I change that to another account without it freaking out?  

Is there a best practices doc that outlines what to do to protect these backups from unauthorized access?

The reseller learned the hard way to manage their uploads to the tune of 5 bitcoin.  (And yes I tested a downloaded file for restore, it was all the files after that that were missing...)




Just check to see what the

Just check to see what the service is running as and that should tell you. The worst you'll need to do is change the account that is accessing the destinations if you are currently using system and the new account doesn't have access.


Newer variants of ransomware

Newer variants of ransomware have the ability to discover SMB shares that are not mapped to a network drive.  Here's a link to a security blog on this topic.

ShadowProtect is not the reason your infection has spread.  We have not discovered anything that has the ability to decrypt your network path configuration from the encrypted ShadowProtect/SPX destination settings.


Just reporting what we observed

"ShadowProtect is not the reason your infection has spread"

Assuming makes an ass out of u and me.  Don't be so defensive your not protecting your market share here.  I'm just letting you know what we observed so that you can be aware of the possibility.  If I didn't think ShadowProtect was a good product I wouldn't use it.  What you have here is a bunch of really smart guys all coming to the same conclusion that something seemed very odd about how this went down.  It went after the backup shares first and deleted them then on to the mapped drives.  We know this because those mapped drives were only partially encrypted before we discovered and stopped this.

Instead of defending yourself maybe that smart move would be to think about and be aware of the possibility.  The entire country of China may have more resources than you think.

Last I am commenting on this, good day sir.



rcsteve, I was trying to help


I was trying to help ease your mind by providing additional information you can use to research this topic on the security blogs, and let you know that the ShadowProtect destination information is encrypted therefore not easily discoverable by any normal methods.  I'm not assuming anything here.

The infection is most likely doing some kind of NETSTAT port/address check, so it finds the addresses of everything that is active for network communication, and thus tries to attack those addresses first.


Pen. testing?

Had any penetration testing done recently?

100% certain that it wasn't a user gaining remote access to the endpoint running SPX and reading the configuration, rather than an automated process discovering the path?


StorageCraft Certified Master Engineer

Veeam Technical Sales Professional (v9)


Thanks -

Thanks for all the resources - I promise to read all.  

Oh, it was user gaining access for certain.  They comprimised a user account and used that from everything we can see.  How that was accomplished remains a msytery to me and the security folks.  I know all of you are analyzing on a really high level but I think it was a simple spoofed website (or similiar) and she probably used the same bleeping password for that account as she does her net logon then entered through our terminal server.  Simple change of her password stopped that attack.      

I am but a lowly admin, but still guys, it was just too directed of an attack.  I'm telling you they knew exactly where to go to hit hardest.  And the account that was used is a normal user account that really doesn't have that much access.  To the shares on the network for sure, but not the ones for the storage.

Let me read the links you have sent, brush up on the lingo a bit and respond again.

Let me ask, is it possible to take a look at the services, follow the traffic and figure out the end destination of the backkup data?  No need to bust into the software to do that right?

I think this thread is headed in a good direction and I am learning things.  Please dismiss my snarky comments earlier, it's tax season at a CPA and the aggravation this caused is off the scale.  Those pr*cks made me miss my son at his district golf tournament.





Task Manager

Just trying to think what I might do if I had bad intentions with access to somebody else's Terminal Server.

Task Manager > Resource Monitor > Network > TCP Connections

Might give someone an idea about where traffic is going. (Local Address & Ports).

That combined with Event Viewer > Windows Application Event Logs > Information > Source 'ShadowProtect SPX'


Then in the 'General' tab, you get an output like:

Backup Finished
Backup "<Job name>" on <server name> successfully finished backing up to <destination name> (\\<backup path>\Backups\).


Don't think it would take long to work it out and then test the general access to that share.


StorageCraft Certified Master Engineer

Veeam Technical Sales Professional (v9)


ShadowProtect/SPX uses the

ShadowProtect/SPX uses the Local System account by default.  It is possible to change the Log On of the service to a different account like a Domain admin account, but if the domain admin password changes then the ShadowProtect service will stop functioning properly until those credentials in the service are also updated.  We don't recommend modifying the service configuration unless absolutely necessary.

Here are some links to some other write-ups on this topic.




Terms and Conditions of Use - Privacy Policy - Cookies