santiago silver - Fotolia

Ransomware protection is futile, but all hope is not lost

It's only a matter of time before a hacker infiltrates your system and holds your files hostage. But there are ways to blunt a Windows ransomware assault.

As if keeping up with patches and the day-to-day headaches of managing Windows systems wasn't enough of a challenge, along comes Cryptolocker, Locker and a host of other variants that have pushed ransomware protection to the top of the list of priorities for many systems administrators.

A few years back, industrious hackers found they could make a decent living by infiltrating systems through various loopholes and encrypt anything within their grasp. With their files held hostage, most victims were forced to deliver a certain amount in bitcoins to the attackers -- or lose their data permanently.

Having an airtight -- and perhaps an air-gapped -- backup system is crucial. What are some other ways administrators can prevent these invaders from crawling through your network and causing havoc? We asked the SearchWindowsServer advisory board members for their advice on ways to fortify Windows systems and throw up roadblocks to make ransomware attacks less dangerous.


Trevor PottTrevor Pott

Ransomware is an absolute pandemic. Threat actors are increasing the complexity and deviousness of their malware with every passing day, and antimalware providers are essentially standing still.

In the case of Windows ransomware, the key to defeating it is to accept that you can't. Eventually, someone will get infected. In the fullness of a time a whole lot of someones will get infected. 

Your option? Do what any commander of a besieged castle does when they know the battle is lost: split the population into small groups and evacuate them under cover of darkness whilst harrying the attackers long enough to escape. Rebuild, resupply and launch a resistance movement.

Start by putting yourself in the context of the virus. If the virus infects a user's computer, under what context can it run? The user's domain account, the local administrator's account, the system account and the network account.

The last -- the network account -- is particularly bad. When something doesn't work with a Windows application, Windows Server and even the Windows client, the solution is often "let's give the network account superpowers." If the ransomware figures out how to execute under the network account context, it can do a lot of damage quickly.

You are not immune to PEBCAK. If it is your computer that gets pwned, who are you logged in under? Are you using an account with elevated privileges? Did you at any point give your account access to sensitive file shares anywhere on the network?

Anything you can access, the ransomware can access. It might even have some zero-day exploits to elevate privileges so your unprivileged account is now a superuser on the remote system.

Uh oh.

Backups need to be on a system that can read all the relevant nodes on your network but with a different authentication scheme. If you can access it from your system, so can the ransomware. So your backup server cannot be directly accessible from anywhere on your network.

Cloud isn't a solution to all ills either. I've recently run across ransomware that knows what keys for Amazon and Azure look like and will gleefully log in to the API and delete everything. Want to bet there's stuff out there that can nuke your Dropbox, Box and so forth accounts?

The ultimate ransomware protection is a backup that is physically disconnected from the rest of your network. The next closest thing is something that can read your network but cannot be written to or controlled by your network.

Do what any commander of a besieged castle does when they know the battle is lost: split the population into small groups and evacuate them under cover of darkness whilst harrying the attackers long enough to escape.

Diversity is key. If you administer a Windows network, try using a Linux or Mac workstation. You can run those Windows administration tools which are only available from a Windows operating system from inside a clean Windows VM. This VM should have nothing in it but the admin tools.

This way, if things go sideways your workstation has a higher chance of not being affected by a Windows-based ransomware running throughout your network. You can keep reverting your Windows VM back to a known good snapshot if it gets infected and resume putting out fires.

Running a different OS -- preferably as part of a different authentication structure than the rest of your network -- also means the person with the administrative superpowers is far less likely to be able to infect the rest of the network if they get compromised.

Everything is about compartmentalization. Focus on making sure that once infected, the damage any compromised system or user account can do is minimal. Try to segment your authentication systems and domains and build hard limits on who can access what and when.

You will be infected. It is inevitable. Accept this and plan for it. Maybe, if you're lucky, when the castle walls are finally breached, the hordes charging through will find you've already evacuated, and there's nothing left to sack.

For more from Trevor Pott, please visit his contributor page.


Michael StumpMichael Stump

Ransomware embodies the evolving threat that malware poses to the enterprise IT world. Gone are the days of highly contagious but largely impotent viruses. Now we're facing a hybrid attack that relies on spear phishing and ransomware to lure users into clicking malicious links.

Once again, the cybersecurity tenet of defense-in-depth is front and center when it comes to ransomware. Because long before a malicious message arrives in a user's inbox, a series of security measures should have scrutinized and quarantined suspected or known threats. In many cases, these security measures include antivirus and antispam. But a growing number of IT shops also utilize DNS scanning, URL filtering and threat-modeling products to supplement traditional security measures.

Of course, defense-in-depth may begin at the perimeter, but it always ends at the desktop. So what can be done in the Windows world to prevent the malicious encrypting of user data? Let's talk about two operational practices that can help: the principle of least privilege and the importance of good backups.

Principle of least privilege

It's bad enough for a user to get hit with ransomware and lose access to personal files on a local workstation. But the damage can be significantly worse when the user has many mapped network drives with access to data belonging to other workers. To limit the damage done by a ransomware infection, manage the level of access and only allow users to access the data they need. In many cases, users only require read access to shared documents on a mapped drive.

If a user with read-only access to files gets infected with ransomware, the malware will not be able to encrypt those files. Remember that malware infections generally run under the context of the user, so if the user cannot modify a file, a malware infection running on the user's desktop will likely be prevented from encrypting it. Yes, the process of managing file and share permissions is time-consuming and repetitive. But would you rather deal with the system-wide upheaval of isolating systems and attempting to recover files from an attack?

Another line of defense? Good backups

What if your defensive capabilities failed to prevent a ransomware infection? It happens. From a backup and recovery perspective, these incidents are less about the cause of the file loss and more about getting files restored. A solid backup plan is nothing without an equally solid recovery plan. And for the sake of clarity, what I would qualify as "solid" is a backup that is not a network-accessible file share with a copy of your data inside. These copies can also be encrypted and lost if the ransomware slips by your defenses.

A solid backup is one that's taken at least once a day and stored in a secure network location -- with no direct user access. Give yourself bonus points if you keep multiple backups for a week or more, as some ransomware infections may go undetected for several days. You don't want to learn the hard way that you've been successfully backing up encrypted data for longer than your retention period.

Ransomware is malware that exploits more than your network's cybersecurity deficiencies; it also lays bare your operational failures. Lock down unnecessary user access and establish more robust backup procedures to put a virtual moat around precious data and prevent attackers from hijacking the business.

For more from Michael Stump, please visit his contributor page.


Timothy WarnerTimothy Warner

The latest trend in ransomware involves delivering a macro-enabled Microsoft Word document to a victim in the hopes he opens the file, enables the embedded macro and allows it to run. Upon execution, the Visual Basic for Applications macro procedure typically invokes a hidden Windows PowerShell console, bypasses its script execution policy and downloads/runs a malicious PowerShell script. This is a bad deal because PowerShell can perform high-level administrative tasks, including encrypting the contents of the victim's hard drives.

In terms of remediating this threat, I would hope that businesses have Microsoft Office installations set with the default macro execution policy. By default, a user needs to explicitly allow macros to run upon opening Office productivity documents.

Of course, the key to this policy is strong user education. Corporate users should resist the urge to blindly bypass security controls; after all, Microsoft Word will let users run macros with a single mouse click.

The same advice -- user education and enabling security controls -- apply to the corporate Windows PowerShell environment. All Windows computers nowadays have PowerShell; by default, PowerShell script execution is disabled on Windows client computers. Additionally, the PowerShell .ps1 script file extension is associated with Windows Notepad; this means that double-clicking a PowerShell script file opens the file for editing instead of executing code.

Nonetheless, it's easy to bypass PowerShell script execution policy, so we should fall back on the critical importance of requiring our users to discriminate when they receive file assets from untrusted sources.

For more from Tim Warner, please vist his contributor page.

Next Steps

Change your approach to protect Windows-based servers

Follow these steps to help prevent ransomware damage

Don't forget to lock down VMs to prevent malware from spreading

Dig Deeper on Windows Server troubleshooting