Fighting ransomware: A fresh look at Windows Server approaches

This electronic evil won't just fade away on its own. Here are a few things you can do

Ransomware is evil, and it continues to prey upon thousands of businesses every year. Most infections are fairly quiet affairs: A small business gets infected, almost always by some employee opening an email attachment he or she mistakes as legitimate but that really contains the payload of a virus. Then several undetected hours later, all of the business’ files—at least those the employee had access to, which in a lot of businesses without good security and permissions policies is all of the files—are encrypted, and demands for payment of a ransom in Bitcoin are made in exchange for the decryption key.

Of course, secure email use and employee behavior is a problem in businesses of all sizes, and there have been some high-profile ransomware infections. Most recently in the news was the attack on the San Francisco Municipal Transportation Agency (SFMTA), or Muni as it is known by Bay Area residents. Muni had to give free trips to all comers over the Thanksgiving weekend while it worked to restore access to its machines. The hacker who infected the utility also claims to have access to 30GB of stolen Muni data; the utility disputes this claim, but it is certainly possible.

If big government and large companies and hospitals can get infected, then everyone can.

I’ve written about ransomware in this space before, but that was ages ago in Internet time. In this piece, I would like to take a fresh look at approaches to combat ransomware. You will note that two of these approaches are predicated on preventing the infection in the first place, because—as the old adage goes—an ounce of prevention is worth a pound of cure. The other approach leaves a bad taste in anyone’s mouth, but it is something that is worth discussing: If you have been victimized by ransomware, should you just pay the ransom, or are there other options?

[ Further reading: 4 signs you’re a victim of ransomware ]

Ransomware ground rules

First, some blanket caveats we should get out of this way.

Your existing antivirus solution is pretty much worthless at detecting ransomware. The ransomware creators have gotten very good at eluding most methods that today’s antimalware software uses to identify and quarantine threats. Unfortunately, far too many organizations think slapping a copy of Symantec Endpoint Protection or something similar on all of their workstations will prevent this kind of malware from infecting their network. This is simply not the case. Antivirus solutions are good at eliminating other threats, but they are extremely poor at detecting ransomware.

Backups are the only legitimate way to avoid paying the ransom. According to the Krebs on Security report, this was the mitigation used by San Francisco’s Muni. “We have an information technology team in place that can restore our systems, and that is what they are doing,” SFMTA spokesman Paul Rose told the Krebs team a few days after the attack. “Existing backup systems allowed us to get most affected computers up and running this morning, and our information technology team anticipates having the remaining computers functional in the next two days.”

I was about to write that backups are the “only foolproof way” to avoid paying the ransom, but that is not the case. You have to regularly and consistently test your backups by restoring them to spare hardware or a virtual machine to make sure they are good—otherwise you have not backed up. If a tree falls in the forest, but there is no one around to hear it, does it make a sound? Similarly, if a backup is made but there’s no way to restore it, have you prepared for a disaster? In a word, no.

User education is also key for preventing ransomware. All of the technical solutions in the world will not help if your users still open up “XLS” and “ZIP” attachments that end up being anything but. Blacklisting and spam control can only go so far, and ransomware comes in with such a wide variety of payloads and covers that it can end up being counterproductive to try to ban, say, all ZIP files or all XLS files from coming into your organization over email. Better to train your users to suspect all attachments are bogus, only open those they know are coming, and delete anything they are not absolutely sure about before opening—or call you.

Use File Server Resource Manager file screens

One of the more unheralded tools in the Windows Server arsenal is the File Server Resource Manager, or FSRM for short. Using the FSRM, you can develop file screens that monitor the activities on the disk of the file server to look for suspicious activities, notify an administrator that something that may be untoward is happening, and then prevent the user from continuing to access those shares. With an FSRM screen like this, an attacker might manage to encrypt a few files, but the screen ought to catch the activity before too much damage is done.

The FSRM design works like this: First, create a file share on your network to act as a honeypot. Regular users would not use the share for anything, but when the ransomware programmatically goes through to attempt to encrypt things, it doesn’t know what shares are normally used, so it just encrypts all of the shares and files it can see. If you see activity in this share, you can safely assume it is ransomware, so then you have FSRM send you an email and then fire off a couple of commands to change permissions in order to block that particular user from further network access.

To get started, install the FSRM from Server Manager (it’s in the Tools menu), and then, once installed, launch the FSRM console from the Start menu. Configure your email notifications—in the right pane, click Configure Options, click the E-mail Notifications tab, and then enter your SMTP server information. You can send a test email right from that screen to make sure everything works.

Next, create a honeypot file share. Use whatever tool you like for this, but make sure you give the Authenticated Users group (this is anyone with an active logon) full access to this share. You might also want to use a special character to force this share to the top of an alphabetically sorted list to hopefully fool the ransomware into starting there first. For example, to do this in PowerShell, you could use this command:

New-SmbShare -Name “$HPImportantFiles” -Path “C:\ClusterStorage\Honeypot” -FullAccess “DOMAIN\Authenticated Users”

Next, in the right pane, click File Screens, and then click Create File Screen. Pick your honeypot share, and then click Define custom file screen properties. Choose Active screening under screening type, and then under Maintain file groups, click Create. Call the group “Honeypot files” and then under files to include, use *.* to include all files. Click OK, then check the box beside your new group in the File Groups box. Click over to the next tab, check Send email, and customize the email to be sent if this screen is triggered. Then click over to the Command tab, and then enter the path to PowerShell.exe on your servers in the first box; in the second box, enter the following:

-ExecutionPolicy Unrestricted -NoLogo -Command “& { Get-SmbShare -Special $false | ForEach-Object { Block-SmbShareAccess -Name $_.Name -AccountName ‘[Source Io Owner]’ -Force } }”

That PowerShell command allows the command to execute, looks for the current share that is being triggered and then blocks access via SMB permissions for that user.

Once you get the machine cleaned up for the user, you’ll want to restore permissions to the honeypot so that your canary in the coal mine can work again. You could do that in PowerShell like so:

Get-SmbShare -Special $false | ForEach-Object { Unblock-SmbShareAccess -Name $_.Name -AccountName ‘userinquestion’ -Force }

Use secured offline backup

The ransomware we are seeing these days is much more sophisticated than the early variants that infected only mapped drives with assigned drive letters and did not know how to navigate Universal Naming Convention (UNC) shares and Windows Distributed File System (DFS) paths. The newest strains of Cryptolocker and its cousins not only traverse the network, they infect the “previous versions,” or shadow copies, that Windows makes of files. (And if they don’t infect them, they instead turn off the volume shadow copy service and then delete the previous versions already present on the disk, making this line of defense no longer suitable to prevent ransomware attacks.) And it is even possible for unencrypted backups to also be infected and encrypted, rendering them absolutely worthless in any effort to avoid paying the ransom.

If you back up to a location that is still connected to the network, your backups are at risk—there is no way around it. This is typically why active backup strategies involving rotating hard drives are best when it comes to defending from these types of threats. Unfortunately, many businesses now rely solely on online backup strategies, backing up to a service in the cloud that by design must always have a network connection—so it is a very simple technical task on the part of the ransomware to encrypt those backups too.

Some tips for effective backups:

  • Add an offline backup as part of your strategy. Back up at least once weekly, and more often if your needs dictate, to tape or spinning media and then immediately disconnect that media from your network and store it somewhere safe.
  • For online backups, ensure that only the right users have permissions to access files and file shares of the files to back up as well as the location where the online backup files are stored.

Should you just pay the ransom?

As distasteful as it may be to reward this kind of hacking, there are some businesses without recent accessible backups that have been hit by Cryptolocker and its relatives that simply have no choice but to take a chance and pay the ransom.

How do you know the hackers will make good on their attempts? To date, there have only been a couple of instances when Bitcoins were transferred but the crackers did not make good on releasing decryption keys. To do otherwise would be tremendously short-sighted: There is no profit motive in simply encrypting peoples’ files, only the small amount of “satisfaction” these crackers would get from causing general mayhem. The profit comes when users trust in the process enough that paying the ransom actually gets their files back.

Word spreads, more computers are infected, more files are encrypted, and there are more opportunities to get ransom payments. If the crackers were to stop honoring the ransom payment, no one would have an incentive to pay, and this undeniably strong black market revenue source would dry up almost overnight.

All of this is to say yes, sometimes your only option is to pay up. But a few tips:

Before you pay, please look at the Bleeping Computer forums in order to see if others in the community have cracked the encryption algorithm of the particular ransomware variant you were unlucky enough to get. Hundreds of keys and additional assistance are available at this invaluable resource.

Don’t be afraid to negotiate with the hacker. Yes, he or she has leverage over you, but you also have leverage—you have the money. There are many reports, especially from midsize and large businesses, of reducing the actual amount of ransom paid by up to 75 percent over the original ransom demand.

Attempt to hide your own identity as much as possible. While most ransomware variants currently do not change the amount of ransom demanded based on the number of related computers they detect are infected, some do, and this is clearly an area where revenue for the hackers could grow.

Try not to let on that your whole business is shut down. Avoid mentioning that n people will be out of work unless you get your files back. Do not mention what type of data is in the files they have encrypted. Say only what you must, and nothing more, to avoid escalation in ransom demands.

This story, "Fighting ransomware: A fresh look at Windows Server approaches" was originally published by Computerworld.

Copyright © 2016 IDG Communications, Inc.

How to choose a low-code development platform