Actually Preventing Ransomware

This post is in response to a preponderance of unhelpful advice posts running around on the Internet with click-baity titles, such as “Top X ways to prevent ransomware in YOUR business!”.  This advice is intended for organizations rather than home users.

A common factor that leads to ransomware problems is failing to implement appropriate controls because of some perceived trade off or ignorance of the risks.  I contend that organizations that make such trade offs are not actually interested in preventing ransomware.  Many organizations and “thought leadership” articles approach ransomware prevention using a combination of awareness training, patching, up-to-date antivirus, and data backups.  But those of us who have been around the ransomware block a few times know that none of these things prevent modern ransomware attacks.

This list of controls is narrowly focused on ransomware – there are many other good controls I don’t mention below.

I ran a most unscientific poll on twitter, and the results are a bit disturbing.  I did not expect the majority of security people responding to state that training can stop most or almost all ransomware.  In retrospect, the question may be badly worded.  Possibly by volume of ransomware training may help, but I don’t expect that to be the case if we consider the spectrum of different attack techniques and malware samples.

At a high level, we need to implement controls that:

  1. Block ransomware from getting to workstations.
  2. Block the execution of ransomware once it gets onto a workstation.
  3. Block propagation of the ransomware once it gets onto a workstation, assuming it executes.
  4. Mitigate the damage cause by ransomware once it gets onto a workstation, assuming it executes.

Controls to prevent ransomware from getting to workstations:

  • Block MS Office file attachments that contain macros (i.e., .docm, .xlsm) and other common executable and script file types in email.
  • Implement web filtering and block access to known malicious sites, sites for which there is little value for the business, and uncategorized sites.
  • Block non-company email and webmail using web filtering and blocking of common email ports at the firewall.
  • Implement ad blockers on web browsers.

Controls to prevent ransomware from executing on workstations:

  • Provide quality ongoing phishing training to employees, paired with phishing simulations.
  • Flag incoming email from the Internet as [external] or similar in the subject line, and incorporate this into the security training program.
  • Apply operating system and application patches promptly after ensuring the patch will not do more harm than good.
  • Ensure that all applications on used on workstations are being managed (i.e., someone is responsible for deploying patches).
  • Disable MS Office macros on workstations.
  • Associate undesirable file types, such as .js, et al, with notepad.exe.
  • Implement application whitelisting to block execution of unknown applications.

Controls to limit propagation of ransomware:

  • Disable SMBv1.
  • Block inbound SMB and RDP connections to workstations.
  • Block accounts with elevated privileges from logging into workstations.
  • Remove local administrator rights from general user accounts.
  • Implement port isolation on the network such that workstations cannot communicate with each other.
  • Use LAPS to configure a unique local administrator account password on each workstation.

Mitigating the damage caused by ramsomware:

  • Monitor file servers and deny permissions to accounts that create particular file types associated with ransomware-locked files.
  • Enable volume shadow copies.
  • Use a backup solution that supports file versioning on workstation and servers.  Periodically test backups with a restore.  Script an alert to detect if backups stop running for some reason.
  • Minimize the number of mapped drives on workstations.
  • Restrict write access on network drives to those people who need to be able to save new versions of files.


I know there are many other good ideas that should be added to this list.  I would be grateful if you can add them below as a comment.  I am thinking about putting this on a publicly editable wiki, with the intention of providing an objective set of controls, and some explanation on the how and why for each.



4 thoughts on “Actually Preventing Ransomware”

  1. Great list. The “tag external emails as such” one is easily done in Office 365 and even Exchange on-premise. Some other thoughts

    – Application whitelisting is critical but difficult to deploy using native MS tools. If you don’t have a test domain or environment, see if your A/V vendor has application whitelisting

    – Implement Web Filtering: This is becoming increasingly difficult in an age of increasing HTTPS-only sites. Your state-of-the-art firewall may do deep packet inspection but it won’t see inside my traffic to Google or Bing unless/until you do TLS inspection. This means finding a box or signing up for a service that can proxy TLS traffic and inspect it. It also means installing certificates on your organization’s devices, so get good at doing that or use Group Policy. THis is super important from a data security & DLP standpoint….all traffic, including malware, is moving to HTTPS and you’re blind to it until you do this

    – Port Isolation/MIcro segmentation: This is also a difficult one to achieve. If you work in a large enough environment, you’ll be tempted to build large broadcast domains for client-side devices, if for no other reason than to ease DHCP scope exhaustion. If you can’t re-architect your network, maybe you can mitigate this problem another way; for instance by enabling your Windows Firewall Advanced Services system via GPO. This is an underutilized tool in me experience; get familiar with it. It’s a great software-defined firewall that’s free. Lastly, if you’ve got any production Domain Controllers sharing a broadcast domain with end-user devices, stop what you’re doing right now and re-architect that. In general, you want to route rather than switch such traffic.

    – It’s super simple to setup your Windows fileserver to monitor for and alert you to and block ransomware attacks in progress. Just bing or google “windows fsrm powershell GitHub” and you’ll find some great scripts that will set this up for you. The way it works is this: your file server will monitor writes and alert you to and block if you choose file system writes that attempt to change an extension to a known ransomware extension. Another option? Talk with your governance or management about removing NTFS permissions to update existing files/folders. Your users won’t like it as everytime they want to edit a document they’ll need to save a new copy, but it works well

    – Script signing: We’re seeing an increasing amount of powershell-based script attacks. You can stop the rifraf script kiddies largely by implementing a solid script execution policy in Active Directory domains using Group Policy. Require that all PS1 scripts are signed before execution; this won’t stop a dedicated attacker but will make your environment more resistant to mass-market style ransomware attacks that are powered by Powershell

Leave a Reply

Your email address will not be published. Required fields are marked *