Ransomware 'Quick' Fixes: Hardening suggestions for your network [Part 2]

This is the second piece of the 3-part guide providing you with a variety of suggestions for hardening your enterprise network against ransomware attacks.

This is the second piece of the 3-part guide providing you with a variety of suggestions for hardening your enterprise network against ransomware attacks. In case you missed it, here is Part 1.

(Note: You know the drill. Infographic at the top, for ease and accessibility, but I would suggest reading on through the rest of the post too).

Alternate Web Browsers and Third Party Applications

While ransomware is still overwhelmingly distributed by phishing emails, it’s not the only attack vector. Malicious advertising (also known as "Malvertising") and Exploit Kits are among other common attack vectors.

Be wary of ad networks and ad delivery

Malvertising is a significant risk, because the fact of the matter is that a majority of advertisers and ad delivery networks don’t really police who is buying ads, where they’re going, and/or what they’re doing. As such, I’m of the opinion that ad blocking should be a no-brainer for enterprise networks.

Screen Shot 2016 08 12 At 12 58 35 Pm
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. If malvertising teaches us anything on this it’s that trusting ad networks and ad delivery networks is ill-advised.

Use a different (better) browser and PDF reader

So, how does this fit into the subject of third party software? Because, I’m going to recommend that you have your users use Mozilla Firefox or Google Chrome as primary web browsers for Internet activity. Of course, there’s always going to be those terrible intranet applications, that your enterprise inevitably standardizes on, that only open in Internet Explorer. So 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, 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. Of course, there are exceptions to the rule, but by and large any functionality beyond these core features are often moot.

Reduce attack surface by getting rid of unused apps

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 that 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 all the same -- but perhaps not as many (due to that smaller codebase). They are also less likely to have exploits adversaries are using in the wild (due to that smaller user base).

Make yourself a harder target by taking the path less traveled

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, to allow them to attack the most victims with the least amount of effort. Make yourself a harder target, and chances are the bad guys will move on to other targets that are softer and easier to attack.

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

Screen Shot 2016 08 12 At 1 03 15 Pm
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.

TL;DR (6 Browser Hardening and App Usage Tips to Remember)

  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 blackholing 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).

Next up, we're going to (nicely) request that organizations stop allowing employees to have so much access to all things.

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

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.

TL;DR (3 main points to keep in mind here...)

  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.

And, last up for this round...

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.

Screen Shot 2016 08 12 At 2 21 26 Pm
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%.

TL;DR (That section shouldn't have been too long to read, but here's the shortened version for you anyway)

  • 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.
  • 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!

To be continued, again...

Not to worry, Part 3 is now at your disposal.

"​The secret of patience is doing something else in the meanwhile."

- unknown -


Close off Canvas Menu