NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
CryptoLocker and a backup strategy
I am requesting the community to evaluate and criticize this approach to CyberLocker We are basically a Windows shop and we are scared to death about the CyperLocker virus. From what I read, ...
Let's summarize this thread. I will open a new thread regarding the Netgear implementation/use of the rsync command.
CryptoLocker and its variants are ‘in the wild’ and using an infected PC to encrypt most files as well as the file and directory names. The malware chases all local drives and any mapped drives as it encrypts the data. Once encrypted users are told to pay a ransom of between $700 and $70,000 dollars in bitcoins or never recover their data.
Currently the only way to feasibly recover the data is either pay a ransom or restore the data from backup files. The backup files should be on a ReadyNAS share that does not have SMB access enabled so the malware cannot detect the data – it is not part of a mapped drive.
The intention is to have backup of various Windows files and directories on a ReadyNAS that are the object of drive mapping in local PC network.
- The backup share should be established without SMB protocol enabled. Turn SMB off in the Network Access tab in the file properties
- The rsync protocol should be enabled and Read/Write access should be allowed. Use the Network Access tab in the file properties.
Now there is a location for file backups that will not be discovered by CryptoLocker.
The next step is to establish a backup job(s) to copy the ‘live’ mapped data to the essentially hidden data area.
CryptoLocker was shut down in the June 2014, and the encryption key was broken in August 2014 (https://en.wikipedia.org/wiki/CryptoLocker). Though of course malware generally is getting more and more sophisticated over time.
Since hidden files and folders can easily be seen in windows (just by choosing the right explorer option), it might not be a very effective countermeasure by itself. Though it does no harm, and could be helpful.
I think you can do better though - keeping the 7 daily shares completely inaccessible from windows (SMB turned off, at least most of the time).
I'm thinking that you back up the PCs to share X daily (say at 0100). Share X is hidden SMB. Then create 7 backup jobs (one for each day of the week) in frontview. Have them start after the daily PC backup normally finishes - say 1300. Each would use incremental rsync. On Monday, back up X to the Monday share; on Tuesday back up X to the Tuesday share, etc.
Thanks for the response. I am looking for ideas and I am not anything close to a UNIX expert and have limited understanding – do not laugh at my questions.
Here is some more of my thinking…
- CryptoLocker is running on the Windows workstations or servers.
- It only knows about the ReadyNAS file data because it was ‘introduced’ to the device location by drive mapping.
- Unlike the predecessor versions it also encrypts directory and file names so confusion reigns supreme during the initial problem evaluation.
- The hidden files on The ReadyNAS need to be specifically addressed by a precise UNC address. Guessing would be equivalent of a brute force attack and probably unlikely for this malware..
- The malware has to go for the low hanging fruit so sophistication probably is not embedded in the code at this time. Doing packet inspection and other techniques is probably not part of its operation.
You said disable SMB for these hidden shares most of the time. That sounds like a great idea since those shares would not need to be accessed except in case of an emergency and the setting could be turned on at that time. In its place would I just use RSYNC as the file protocol??
You described the backup as I envisioned it – multiple days each independent of the other using the ReadyNAS backup capability – disk to disk operation.in our case within the same cabinet.
Just a point of clarification CryptoLocker has not been shut down; Version 3 is now infecting client systems. The June 2014 ‘capture’ was good but it is now history with a substantially more robust version with different distribution. The Wikipedia article is outdated. Additionally the payments now range from $700 to over $70,000 all payable in bitcoins.
Here are some recent references.
http://blogs.wsj.com/cio/2015/11/10/ransomware-attacks-to-grow-in-2016-says-intels-mcafee-labs/
http://www.wsj.com/articles/paying-ransoms-to-hackers-stirs-debate-1447106376
https://securityledger.com/2015/10/fbis-advice-on-cryptolocker-just-pay-the-ransom/
https://www.backblaze.com/blog/locker-cryptolocker-progeny-awakens/
Thanks for clarifying the cryptolocker info. As your links point out there is other ransomware too.
Bains wrote:You said disable SMB for these hidden shares most of the time. That sounds like a great idea since those shares would not need to be accessed except in case of an emergency and the setting could be turned on at that time. In its place would I just use RSYNC as the file protocol??
You described the backup as I envisioned it – multiple days each independent of the other using the ReadyNAS backup capability – disk to disk operation.in our case within the same cabinet.
Yes, I was thinking there'd be one hidden SMB share used as the windows backup destination, and 7 rsync protocol shares (perhaps with https also enabled, so you check on them easily). You'd enable SMB either to audit them, or to restore data - otherwise it would be off.
Note to do this you'd need to set up the rsync backup jobs' source as an rsync server, using 127.0.0.1 as the source IP address.
Thanks
Cleaver solution -- shares without SMB. I would not have thought of that.
I will try a sample approach and ask quetions if issues occur.
I posted an upgrade question related to this issue -- you will probably comment on that as well.
Puzzled.
I changed our test location to remove SMB protocol and add RSYNC.protocol.
At that time it seemed to eliminate a lot of data but I did not care.
I changed our test backup job.to go from one share to the Test share (no SMB access, only RSYNC)
Did not encounter any issue.
Ran job and it worked.
I did not encounter the backup jobs' source as an rsync server, using 127.0.0.1.
Did I flub this test?
Bains wrote:
Puzzled.
I changed our test location to remove SMB protocol and add RSYNC.protocol.
At that time it seemed to eliminate a lot of data but I did not care.
I changed our test backup job.to go from one share to the Test share (no SMB access, only RSYNC)
Did not encounter any issue.
Ran job and it worked.
I did not encounter the backup jobs' source as an rsync server, using 127.0.0.1.
Did I flub this test?
What settings did you use?
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
