June 16 2021 Wednesday
Ransomware Prevention Part 6 - GPO tricks and tips
Part 6 - GPO tricks and tips
See here for the entire series of posts, if you are just stumbling onto these posts.
As I said in part one, these post are supposed to be helpful in giving you meaningful useful advice to prevent ransomware.
If you only read one of this series, this one should be it. Seriously. And read it all a few times before you start editing the default domain policy!
Most of this series is dedicated from stopping any potential ransomware from getting to the install or execution point. But what happens if all your many Darren-approved, onion skin layers of security fail and the nasty does get through and it does execute? In this worse case scenario GPOs or Local Security Policies (if you are not AD joined) are your friends. I have implemented the techniques in this post to prevent whack-a-mole reoccurrences of a Ryuk ransomware attack. These techniques are that powerful.
The basics - how ransomware works
A rather large caveat. Your users should not be local Windows admins on their machines. If they are you have a somewhat larger issue to fix. The fix being "stop doing that".
If your users are not local Windows admins then how does ransomware execute and install? Simple, it installs and/or runs in the users local profile context. That handy c:\users\\ folder. The one that the likes of WebEx, Zoom, Teams, et al all install and run from. Yeah, there.
So the same useful Windows features that lets you work from home, do video calls and not wear anything below the waist is also the same mechanism ransomware uses to install and execute. Ransomware is usually a series of different malware applications, each with a specific use case. There is some type of "dropper" that is what the unwitting user clicks on, downloads, allows a MS Office macro to run, or otherwise executes. Once the dropper is in place it will attempt to install one or several different programs from the internet to gain a foothold in your network, These "several different things" (that can happen over a series of days, weeks or months so you do see them for what they are) include:
A few years ago step 2 was relatively uncommon. Not anymore as it appears to be pretty good leverage at getting you to pay. Not necessarily to decrypt your data, but to get the hackers to promise they will delete this exfiltrated, sensitive data and they will not publicly release it. A promise. What could possibly go wrong.
In step 1 and 2 the hackers are almost always looking for server based file shares or access into server operating systems (think SQL Server, Exchange, etc) these days. The idea being that the more users I can affect with one attack the more likely you are to be willing to pay. If I encrypt just your files you are unlikely to pay. If I encrypt critical, run your business files that 10, 100, or 1000 users require to work then the pain increases by many orders of magnitude.
Pro-tip, don't pay. Follow this series (this post the the upcoming backup one especially) and you won't have to. I really need to do a "what if you pay" post at some point to so you realize paying for decryption isn't all they promise it will be.
OK, so now we know where and how this stuff works, how do you stop it if none of the other 8+ posts in this series saved me? You prevent it from running.
Prevent it from running in the first place
You prevent it from running by whitelisting. Now just the term whitelisting sends IT professionals off into the woods to remove their clothing, revert to their prehistoric selves never to be seen again. But hear me out before you quit, strip off and go full on paleo in the wilderness.... So long as your users are not local admins and have no rights to install software in to Program Files, etc. then all you need to do is to whitelist applications that you wish to specifically allow to run inside the aforementioned appdata context. This is much, much smaller nut to crack. Why? Because next to nothing *should* be running from the user profile or appdata folder (I say *should* because there are usually way more than you would expect).
Inside your Active Directory Group Policy Object (GPO) and the local security policy is a handy little thing called Software Restriction Policies (SPR). SRPs can be set to not allow anything to run in a specific folder on a Windows device. Additionally the SRP can be expanded to allow only what you want to run:
With a SRP you can easily block exe, Powershell, Zip, 7z, rar, etc. from running is a users appdata context (this is also where the users temp is located to which is another execution hotbed).
Below is an actual SRP. Notice the security level column? Disallowed means you're not running. Using a disallow with a path rule and using Windows environment variables your can simply and effectively block all exe's for all users appdata contexts. Conversely a security level of unrestricted will allow anything that matches to execute. In this example anything signed with the uploaded Adobe Inc signing certificate will be allowed to run, as is AMD, Barracuda, etc.:
SRPs can be set to allow four different ways:
The problems with SRPs
Well, quite simply they stop stuff working by design. When you enable them, programs that previously worked could just stop. This means you need to build out your exception list as fully as possible before enabling the policy. Scour your users appdata folders for exes and you will find (and be able to extract and upload signing certificates) the likes of Adobe, Teams, WebEx, Zoom, Go To Meeting, BlueJeans and all kinds of other web conferencing tools you never heard of. All of these most likely need to be added. Note, most of the web conferencing tools also have a "machine wide" installer that forgoes the need for each and every user to download and these tools. As these machine-wide installers utilize Program Files folders they don't fall foul of SRPs (when you create an SRP the GPO auto-add exceptions for this file path). Start with a small set if users and work out from there.
The 2nd issue is find out what was blocked and why. When a block occurs the user is shown this not very useful error:
Doesn't tell you what was blocked or why. For that you have to look at the local machines event log. If a cunning user or hacker copies a exe to their user profile folder and executes it, not only will they see the message above, but something along the lines of this will be written to the event log:
Obviously managing this for even a small number of PCs can be time consuming when you first enable these policies, so if you have some type of central logging system you can better report on the things that are happening and/or need to be added as exceptions. Here is a SIEM (Eventlog Analyzer) that shows a blocked 7z execution:
With a SIEM (or any other reporting solution that extracts local event logs) it becomes much easier to proactively manage SRPs. For instance you can send a report to your security team listing yesterdays blocks. They can then investigate.
Scheduled Tasks
Another common attack area of ransomware is to install innocuous looking scheduled tasks that will attempt to reinfect or re-detonate the malware tools on reboot or on a scheduled basis. There is little use in a regular, non-admin users being able to create a Windows OS level scheduled task, so simply preventing these users from creating them is simple and effective way to head off this line of attack. This is available in the computer and user policies under Administrative Templates, Windows Components, Task Scheduler. Simply prohibit new task creation:
Conclusion
While one can never guarantee an attack will be prevented (SolarWinds anyone?), whitelisting is about as close to a guarantee as you can get. Added to the onion-skin of protection you build around your devices and (touch wood) you will never have to contemplate paying a ransom or restoring from backups. It is also worth noting that Microsoft has several different options to SPR, AppLocker being the most obvious other choice. Either is fine, I just do a lot more SRP than anything else.
See here for the entire series of posts, if you are just stumbling onto these posts.
As I said in part one, these post are supposed to be helpful in giving you meaningful useful advice to prevent ransomware.
If you only read one of this series, this one should be it. Seriously. And read it all a few times before you start editing the default domain policy!
Most of this series is dedicated from stopping any potential ransomware from getting to the install or execution point. But what happens if all your many Darren-approved, onion skin layers of security fail and the nasty does get through and it does execute? In this worse case scenario GPOs or Local Security Policies (if you are not AD joined) are your friends. I have implemented the techniques in this post to prevent whack-a-mole reoccurrences of a Ryuk ransomware attack. These techniques are that powerful.
The basics - how ransomware works
A rather large caveat. Your users should not be local Windows admins on their machines. If they are you have a somewhat larger issue to fix. The fix being "stop doing that".
If your users are not local Windows admins then how does ransomware execute and install? Simple, it installs and/or runs in the users local profile context. That handy c:\users\
Ransomware (usually) runs in the user profile folder.
So the same useful Windows features that lets you work from home, do video calls and not wear anything below the waist is also the same mechanism ransomware uses to install and execute. Ransomware is usually a series of different malware applications, each with a specific use case. There is some type of "dropper" that is what the unwitting user clicks on, downloads, allows a MS Office macro to run, or otherwise executes. Once the dropper is in place it will attempt to install one or several different programs from the internet to gain a foothold in your network, These "several different things" (that can happen over a series of days, weeks or months so you do see them for what they are) include:
- Reconnoiter - find what is on the network, what it can get to, find lateral move points and search for systems to compromise (meaning un-patched known, exploitable vulnerabilities).
- Exfiltrate - take your data off-site so if you don't pay the ransom to unlock your files, they can still have leverage over you and threaten to release sensitive information.
- Encryption engine - the program that will download a public key (almost always AES, so to all intents and purposes uncrackable) from a command and control server. It then begins to encrypt items located in 1. Encryption usually begins at the start of a weekend to give the ransomware enough time to do real damage based on the hope that no one is looking at the servers on a weekend. Mondays can be very bad.
- Profit.
This is about as simple as it gets. Find your stuff. Steal your stuff. Encrypt your stuff. Profit.
A few years ago step 2 was relatively uncommon. Not anymore as it appears to be pretty good leverage at getting you to pay. Not necessarily to decrypt your data, but to get the hackers to promise they will delete this exfiltrated, sensitive data and they will not publicly release it. A promise. What could possibly go wrong.
In step 1 and 2 the hackers are almost always looking for server based file shares or access into server operating systems (think SQL Server, Exchange, etc) these days. The idea being that the more users I can affect with one attack the more likely you are to be willing to pay. If I encrypt just your files you are unlikely to pay. If I encrypt critical, run your business files that 10, 100, or 1000 users require to work then the pain increases by many orders of magnitude.
Pro-tip, don't pay. Follow this series (this post the the upcoming backup one especially) and you won't have to. I really need to do a "what if you pay" post at some point to so you realize paying for decryption isn't all they promise it will be.
OK, so now we know where and how this stuff works, how do you stop it if none of the other 8+ posts in this series saved me? You prevent it from running.
Prevent it from running in the first place
You prevent it from running by whitelisting. Now just the term whitelisting sends IT professionals off into the woods to remove their clothing, revert to their prehistoric selves never to be seen again. But hear me out before you quit, strip off and go full on paleo in the wilderness.... So long as your users are not local admins and have no rights to install software in to Program Files, etc. then all you need to do is to whitelist applications that you wish to specifically allow to run inside the aforementioned appdata context. This is much, much smaller nut to crack. Why? Because next to nothing *should* be running from the user profile or appdata folder (I say *should* because there are usually way more than you would expect).
Inside your Active Directory Group Policy Object (GPO) and the local security policy is a handy little thing called Software Restriction Policies (SPR). SRPs can be set to not allow anything to run in a specific folder on a Windows device. Additionally the SRP can be expanded to allow only what you want to run:
SRPs - block everything, except what I specifically allow.
With a SRP you can easily block exe, Powershell, Zip, 7z, rar, etc. from running is a users appdata context (this is also where the users temp is located to which is another execution hotbed).
Below is an actual SRP. Notice the security level column? Disallowed means you're not running. Using a disallow with a path rule and using Windows environment variables your can simply and effectively block all exe's for all users appdata contexts. Conversely a security level of unrestricted will allow anything that matches to execute. In this example anything signed with the uploaded Adobe Inc signing certificate will be allowed to run, as is AMD, Barracuda, etc.:
SRPs can be set to allow four different ways:
- Path - specify an allowed file or folder path (i.e. %appdata%\Temp\Teams\*). This is the most insecure type as *anything* in that folder will be allowed to execute, and hackers know many common folders (a lot of malware adds folders called Google Chrome or Chrome to these paths). It is also the easiest exception to add. Try your hardest to not use this type of exception. Very good for disallow rules. This is, after all, what you are trying to prevent.
- Hash - the file hash of a selected exe. This is also pretty easy to allow, but *ANY* change to the file (so an upgrade to a new Zoom version that replaces zoom.exe) will prevent it from running as those file hashes no longer match. Use this for vendors who refuse to use signing certificates (also find a new vendor).
- Network zone - I'm going to skip this as it's of little use when trying to protect a local machine, and using this could seriously increase your risk to lateral movement of malware in the network.
- Certificate based - the most difficult to do as you need to extract and upload the digital signing certificate from an exe to the SRP (and sometimes more than one). It is also not enabled by default. It is however the most secure (only exe's signed with said digital certificate can run) and it bypasses the issues with hashes as upgraded versions of programs (like zoom.exe) are likely to be signed with the same signing certificate. Certificates do expire or are revoked so this is not quite fire and forget. Indeed just the last few weeks Bitdefender changed signing certs so these had to be updated.
The problems with SRPs
Well, quite simply they stop stuff working by design. When you enable them, programs that previously worked could just stop. This means you need to build out your exception list as fully as possible before enabling the policy. Scour your users appdata folders for exes and you will find (and be able to extract and upload signing certificates) the likes of Adobe, Teams, WebEx, Zoom, Go To Meeting, BlueJeans and all kinds of other web conferencing tools you never heard of. All of these most likely need to be added. Note, most of the web conferencing tools also have a "machine wide" installer that forgoes the need for each and every user to download and these tools. As these machine-wide installers utilize Program Files folders they don't fall foul of SRPs (when you create an SRP the GPO auto-add exceptions for this file path). Start with a small set if users and work out from there.
The 2nd issue is find out what was blocked and why. When a block occurs the user is shown this not very useful error:
Doesn't tell you what was blocked or why. For that you have to look at the local machines event log. If a cunning user or hacker copies a exe to their user profile folder and executes it, not only will they see the message above, but something along the lines of this will be written to the event log:
Obviously managing this for even a small number of PCs can be time consuming when you first enable these policies, so if you have some type of central logging system you can better report on the things that are happening and/or need to be added as exceptions. Here is a SIEM (Eventlog Analyzer) that shows a blocked 7z execution:
With a SIEM (or any other reporting solution that extracts local event logs) it becomes much easier to proactively manage SRPs. For instance you can send a report to your security team listing yesterdays blocks. They can then investigate.
Scheduled Tasks
Another common attack area of ransomware is to install innocuous looking scheduled tasks that will attempt to reinfect or re-detonate the malware tools on reboot or on a scheduled basis. There is little use in a regular, non-admin users being able to create a Windows OS level scheduled task, so simply preventing these users from creating them is simple and effective way to head off this line of attack. This is available in the computer and user policies under Administrative Templates, Windows Components, Task Scheduler. Simply prohibit new task creation:
Conclusion
While one can never guarantee an attack will be prevented (SolarWinds anyone?), whitelisting is about as close to a guarantee as you can get. Added to the onion-skin of protection you build around your devices and (touch wood) you will never have to contemplate paying a ransom or restoring from backups. It is also worth noting that Microsoft has several different options to SPR, AppLocker being the most obvious other choice. Either is fine, I just do a lot more SRP than anything else.
Just to add that the Teams machine-wide installer does in fact install to Program Files but all it does after that is install Teams to the user's appdata folder.
"Note, most of the web conferencing tools also have a "machine wide" installer that forgoes the need for each and every user to download and these tools. As these machine-wide installers utilize Program Files folders they don't fall foul of SRPs"