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.

 

 

Nightmare on Petya Street

Just some notes for myself that others may also find useful:

Initial propagation allegedly Medoc auto updates, though vendor denies it

Image posted on twitter, attribution intentionally missing:

https://twitter.com/thedefensedude/status/879764193913716737

Good write up by Brian Krebs indicating how the malware obtained credentials to propagate
Mitigations:

Create c:\widows\perfc.dat and make it read only:

https://twitter.com/hackingdave/status/879779361364357121

Apply MS17-010 and disable admin$ shares via GPO

After reboot, system appears to be running fsck, but this is actually files being encrypted.  Shut the system down immediately if that happens to enable file recovery using a boot disk.

Never Let A Serious Cyber Crisis Go To Waste

For nearly a week now, a non-stop parade of news reports berated the UK’s NHS, who temporarily suspended operations at some hospitals due to WannaCry infections, for their continued use of Windows XP.  An example is this one.  This article points out, and many other news stories also report, that Citrix obtained a response to a freedom of information (FoI) request which indicated “that 90% of hospitals still had machines running on Windows XP”.  There is no indication of how big the problem really is, though.  If 90% the hospitals had a single XP-based ATM, that would be reported the same as if each of those hospitals ran tens of thousands of XP systems.  Indeed another report on the survey had this to say:

The trusts that provided details said Windows XP made up a small part of their overall PC estate — one said it was 50 out of 5,000 PCs, for example.

A bit of Googling reveals that Citrix sent an FoI request to 63 out of more than 200 NHS trusts, and received responses from 42 (source).  The survey was almost certainly intended for marketing purposes by Citrix, intended to help sell more of their product.  We should be wary about that stat.

Now come reports that XP systems really were not commonly infected.  Various discussions on Twitter even indicate that XP SP3 is not susceptible to WannaCry infections.

There are people who are clearly angry with the NHS for its continued use of XP, and that is probably well founded.  However, the angry stories tenuously linking XP in 90% of NHS hospitals to the services outages experienced at those NHS hospitals, apparently completely misses the point: if we want to beat up on the NHS about something related to it’s WannaCry woes, we should go after their failure to patch Win7 and/or Win2008 in a timely manner.