This is a side-trip regarding cryptolockers with regards to the backup part of the OP.
The different varieties of lockers we have seen where I do my daily work has been targeted locally to certain business including language, specific parts of the organisations, etc. Most of them, if not all, is pretty much a official looking email that leads to a landing page where you download a document, often hidden behind a captcha, so automatic linking and scanning/sandboxing can't download the actual malware before the user does it. Behind the captcha, or the landing page has been anything from what amounts to Russians version of google-drive, to hacked webservers, containing a page deep down under several folders where the original page never link. But yeah, there have also been infected ad-servers spreading popups that user browser vulnerabilities... very often flash, java, etc. One problem with many sandboxing technologies is that they take a few minutes to block the actual malware since they need to analyze it, so they often caught any attempts a few minutes after the first attempt. Now, depending on your security setup, scanning, sandboxing, proxies, etc, you can often block the callback itself, since they might be classified as malicious even without your sandbox having seen it. So while the download has been down, most lockers doesn't activate without having done a callback.
I work for a security company as a consultant, and we also offer a free DNS service that anybody can use if they want to.
https://www.mnemonic.no/news/2015/free- ... s-service/There are also other free services from certain companies that offer some measure of protection. Running EMET is a thing I would not be without if you are using windows and especially IE.
Bluecoat have their free K9 Client you can use as well.
DrCR wrote:Aphasia wrote:And I also don't have it mapped as a drive at all, but always use an UNC path if I need to read something. The same practice goes for the fileserver, where I have a specific backup-user configured on the filesyncing software that has write access to the nas. And no mounted shares at all, everything is done through UNC paths.
Does that really matter? Just curious. I recall one poster recently stating the properly right way would be via SSH.
Depends what you are after. Many programs can use UNC, but not SSH, unless you get something specifically syncing over SSH. And if UNC or not helps, that depends on the malware. Most lockers currently starts encrypting all files you can access as a user, so any mapped drivers where you have write credentials are considered a risk. So yes, not having it mounted and only having read access from your running account and any admin accounts is a very easy step, since you shouldn't have any need to actually access your backups unless you are doing a restore or maintenance. Although it's the read only access that is the most important step. But why have it mounted at all if you don't need it.
Now there is malware that scan the network for hosts and looks for open shares as well, but currently I haven't heard of a specific cryptolocker type malware that actually extracts credentials from installed syncing software and use that to try to access the shares. It usually runs under your own account, and often with admin rights if you haven't limited them, as is way to common in a home setting.
As for UAC, etc, that is quite easy to bypass as long as you can throw up some form of user interaction.
What does the most difference is the user not clicking on any stupid sh*t that turns up in their browser or mailbox. But if they do, dns blackholing, automatic blacklisting of urls, etc to block callbacks is a nice thing to have with regards to cryptolockers, but it's only a matter of time until they get around such things as well, but those are not without inherent vulnerabilities to be exploited to decrypt the files as well.