Ransomware Protection Part 2: Hardening Strategies to Secure Your Enterprise

In Part 1 of this multi-part blog post we discussed network hardening strategies to defend against ransomware. Some of the details we covered were how to improve user awareness on phishing, as well as what you can do to have better email security practices.

In this next part, we will be talking about access control and file or network share permissions, alternative app usage and browser hardening techniques, application whitelisting, software restriction policies, and more best practices that are important for you to be aware of.

Alternate Web Browsers and Third Party Applications

While ransomware is still overwhelmingly distributed by phishing emails, this is not the only attack vector. Malicious advertising (malvertising) and exploit kits are among other common attack vectors.

Be wary of ad networks and ad delivery

Malvertising is a significant risk. The majority of advertisers and ad delivery networks don’t do much in the way of policing who is buying ads, where they’re going, and/or what they’re doing. As such, I’m a fan of ad blocking and my opinion is that this should be a no-brainer for enterprise networks to implement.

UBlock Origin is a great ad blocking extension.

It can be argued that loading and running ads in one’s browser is more or less remote code execution (RCE). If malvertising teaches us anything, it’s that trusting ad networks and ad delivery networks is ill-advised.

Use a different (better) browser and PDF reader

How does this fit into the subject of third party software? Well, it’s because I’m going to recommend you have your users use Mozilla Firefox or Google Chrome as primary web browsers for Internet activity.

Of course, there are always going to be those terrible intranet applications–that your enterprise inevitably standardizes on–which only open in Internet Explorer. Therefore, you can never truly be rid of it. In any case, both Firefox and Chrome have group policy profiles that can be used to manage their configuration settings via GPO, and there are guides available for pushing Adblock extensions automatically as well.

In addition to using different (arguably better) browsers, consider using an alternate PDF reader as well. Sumatra, Nitro, and Foxit are all great alternatives to Adobe Reader. Personally, I use Foxit, and it has an excellent feature called “Safe Reading Mode” turned on by default. This feature prevents embedded JavaScript from making web connections, and running external commands or other functions associated with malicious PDF documents.

Adobe Reader Versus Foxit

To compare, I pulled down the latest version of Adobe Reader, called Adobe Reader DC and compared it to my daily driver PDF reader: Foxit Reader. Adobe weighs in at 90+ MB, while Foxit is nearly half of that.

Where is all that extra space going? According to other researchers, it’s going into features your everyday user will likely never use. I often like to joke that email is a perfect example of scope creep, but I think Adobe Reader has them beat.

According to research, Adobe Reader can embed audio, video, and 3D drawings (CAD), supports DRM, document tracking/management, and a whole host of other features. Your standard user likely only needs a PDF reader to be able to do two or three things: Open PDF Files (which interestingly enough, both Mozilla Firefox AND Google Chrome can handle natively), allow the user to fill out forms in the PDF (including digital signatures), and print the PDF. There are exceptions to the rule, but by and large any functionality beyond these core features are often moot.

Get rid of unused apps to reduce attack surface

One of the basic tenants of computer security is reducing attack surface as much as you can. So, if you don’t use an application, feature, or service, turn it off or disable it.

In addition to reducing attack surface, there’s another well-known methodology: KISS (Keep It Simple, Stupid). Adobe Reader does none of these things. You can’t disable the extra features Adobe helpfully jams into Reader (regardless of whether or not you want /or/ need them), and of course, this makes Adobe Reader anything but simple.

As code complexity in a project increases, the likelihood of bugs also increase. As you might imagine, bugs could mean vulnerabilities, exploits, and attacks on your users. You now probably have an inkling as to why Adobe Reader seems to be constantly getting hit with updates and security bulletins. These exploits end up in targeted attacks, exploit kits, etc. The thing about them is, for the exploit to be successful, you have to be running the vulnerable application. If you’re using a third party application for similar functionality, you’re reducing your risk of attack, but you are /not/ eliminating it.

Let me be clear on that.

When you use an alternative or third party application, you’re trading one set of vulnerabilities for another. In the case of Sumatra, Foxit, etc. they have a smaller feature set and codebase–they’ll likely have vulnerabilities, but perhaps not as many due to the smaller codebase. They are also less likely to have exploits adversaries are using in the wild, again, due to the smaller user base.

Take the path less traveled to make yourself a harder target

Adversaries make assumptions that enterprises run Windows, Internet Explorer, Adobe Flash/Reader, and utilize the Microsoft Office suite when they craft their exploits and/or payloads. If you change some of these things, or modify their default settings, then you make your enterprise and your users a harder target.

The attackers are looking for the most widely used software, that will have the biggest installation footprint, which allows them to attack the most victims with the least amount of effort. Make yourself a more challenging target and chances are the bad guys will move on to others that are easier to attack.

Check out Ninite to make yourself aware of free and/or alternative applications.

Ninite comes in a free, personal edition for home users. It also has an enterprise edition for enterprise networks.

Ninite has a huge variety of free applications that their installer will grab for you and handle the installation tasks automatically, while ensuring that any additional bloatware packaged with the products you want does not get installed.

6 Key Points (tl;dr)

1. Standardize on an alternative Web Browser

   Chrome, Firefox, doesn’t matter. Deploy either with ad blocking add-ons such as uBlock origin. If you need help with this, here is a nice guide for deploying Mozilla Firefox ESR and uBlock origin. Failing Adblock, implement DNS black-holing to achieve the same goals in a pinch.

2. Disable Adobe Flash and/or Java web plugins

   If it’s at all within your power to do so, disable adobe flash and/or java web plugins in your alternate browsers to further reduce your attack surface.

3. Utilize IE Administration Kit to restrict access

   If you have to have Internet Explorer, Java Web and/or Flash, for some sort of a legacy intranet application or third party partner site, consider using the Internet Explorer administration kit to configure IE to restrict access to just those sites where Internet Explorer is required.

4. Have a PDF reader built in for viewing-only needs

   If all your users need is a PDF viewer, both Google Chrome and Mozilla Firefox have a PDF reader built in.

5. Investigate alternative PDF applications

   If your users need the ability to sign, fill out (and/or digitally sign), and/or print PDFs, investigate alternative PDF applications (Sumatra, Nitro, Foxit, etc.) aside from Adobe Reader.

6. Utilize alternative apps where possible

   Utilize other alternative applications where you can to decrease your attack surface. Check out Ninite for a list of free applications to consider (as well as a great solution for deploying them).

Role-Based Access Control and Granular File/Network Share Permissions

Bottom line: what I’m requesting here is to stop allowing your employees to have access to so many things.

This one can be a bit more painful than most realize, especially if you work in an organization where the culture of EVERYONE GETS LOCALADMIN! Is rampant. When users are used to running around with admin access, installing whatever they want, whenever they want, with next to nothing to stop them, taking that away makes you an enemy of the user community very fast. Generally speaking, people don’t like it when you take things away from them, even if it’s for their own good.

File and share permissions are something that the adage of “limit user privileges” doesn’t really touch upon all that often, if at all. However, when relating to ransomware, file share permissions could be the difference between one workstation, one network share, or half the company’s files getting encrypted.

Ransomware has never had a problem with mapped network drives and will happily encrypt anything the current user has write access to without a care in the world. However, newer ransomware variants will actively seek out network shares (mapped or not) that the user can write to, and go for them as well. That means writable shares, available to “Everyone” or “Authenticated Users” that you are using for administration and patch management, could be at risk if the users can write to those shares–let alone writable network shares for other business units.

It’s very hard, grueling work to figure out user, file, and network share permissions, how they all interact, and the right mix of each to ensure different roles and business units have the access required to perform their job functions. It involves understand the mission of each group, what functions they provide, and mapping those functions into minimum access controls necessary to do the job. Even once it’s done, you’ll occasionally need to audit those permissions and ensure that they’re still accurate. The bright side is that once it’s done, it’s easy to make user profile templates, and once groups are established with the correct permissions, everything falls into place much easier.

3 Key Points (tl;dr)

1. Users must have a VERY compelling reason for local admin access

   Your users should not have local administrator access, unless there is an extremely compelling reason. “Because I need it for my job!” or “I want it!” is not a compelling reason.

2. Only grant read and/or write access to file shares as necessary

   File Permissions and Network Share permissions need to be considered as well. Read and/or write access to file shares should only be granted as necessary.

3. It’s not an easy process, but there’s a bright side (and it’s worth it)

   This is one of those “easier said than done” security controls. This isn’t going to be easy by any stretch of the imagination. It will involve analyzing business unit workflows, positions within the business unit, and tasks each position is required to perform, then breaking down those tasks into the minimum access requirements. The bright side is, that once it’s done, user role and group templates are very easy to roll out.

Application Whitelisting, Software Restriction Policies, and Disallowing Execution from TEMP Directories

Typically when attackers manage to successfully exploit a system, they’ll drop some sort of an executable that does the hard work. It may be the main payload, or it may be a dropper for another payload. Typically, these payloads execute from C:\Windows\temp (%WINDIR\temp) or the user’s APPDATA directories.

Application whitelisting is built into Windows as a feature called “Software Restriction Policies”. Not unlike RBAC, application whitelisting is another one of those looks great on paper/easy, but can be tough to master. Also, not unlike RBAC, it requires knowing what applications different business units use on a regular basis, then telling windows: “Run nothing but these applications, in these locations.”

An intermediate step would be configuring a software restriction policy to restrict applications attempting to execute out of a user’s temporary directory or the windows temp directory. It’s not a perfect solution by any stretch (in fact, it can break WebEx, as well as some other applications that intentionally do this for whatever reason), but it is another layer of defense.

If you want to read up on SRP, believe it or not, the NSA’s IAD (Information Assurance Directorate) is a go-to source on that, among other computer security topics.

This is an old SRP used to try and prevent cryptolocker. This image is courtesy of a nice ransomware prevention guide hosted at bluesoul.me.

If you’re looking for an application whitelisting starting point, consider experimenting with blocking applications that attempt to execute out of C:\TEMP, C:\WINDOWS\TEMP, %APPDATA%, and/or %LOCALAPPDATA%.

2 Key Points (tl;dr even though this section wasn’t that long)

1. Determine individual app purposes and then set up SRPs

   Application Whitelisting is something to consider while you’re meeting with business units about role-based access control. Figure out what applications are used for what purpose and by what business units, then set up SRPs (Software Restriction Policies) to allow only those applications to run.

2. Or, as a go-between step, you can use cryptolocker SRPs

   As an intermediary step, you could use the cryptolocker SRPs available here and block execution from %WINDIR%\temp\, %APPDATA%, and %LOCALAPPDATA%. Make sure you test before deploying!

Part 3

Not to worry, Part 3 is now available!