Hardly a week goes by without news that some company, municipality or other organization has been hit with a ransomware attack. In an instant, critical computer files and systems that the organization relies upon to conduct business become inoperable, and the criminals demand a ransom based on the perceived ability to pay.
Since 2013, when the first strains of ransomware began appearing, there’s been a simple and well-known preventive step for Windows systems that run in an administered network environment. It’s proven extremely effective at keeping most forms of ransomware from encrypting files and holding systems hostage. First, we’ll explain why, and then share the how.
Ransomware’s Favorite Hiding Places
To evade signature-based antivirus software, criminals are constantly introducing new variations of their ransomware. That’s why antivirus software often fails to stop it, and organizations continue to suffer the consequences. However, there’s one thing that all ransomware has in common: it has to be able to execute. In all cases we’ve found so far, the file containing the encryption engine needs to live somewhere in the folder structure on a targeted system.
The infection process is typically launched by tricking the user with a phishing attack, although it can happen by other means. Regardless of the chain of events, at some point, executing the payload that encrypts the files requires that it be in a location where:
- The operating system (and any security software) allows the executable file to be planted;
- The process is allowed to start; and
- It can all happen without tipping off the user until it’s too late and all the files are encrypted.
Criminals have found that the best place for making sure that all three things can happen is in a temporary folder, or in an AppData folder (the location where properly installed applications store their data files in Windows). Under normal circumstances, an executable file should never run from one of these locations. They’re for holding data, not housing executable files.
Group Policy Object: No Running Allowed
Group Policy Objects (GPOs) are built into ActiveDirectory, where they allow administrators to enforce policies on the networked computers. They do everything from dictating screensaver timeouts to enforcing password policies. One of the options offered is preventing executable files from running in certain places on the machine. With the proper GPO in place, even if the criminal succeeds in planting the executable, the file-encrypting payload won’t run.
Putting a GPO policy in place requires administrator privileges. We recommend testing the GPO in the production environment to make sure that some random but otherwise legitimate program hasn’t broken the normal protocol by placing an executable in one of those places. That’s rarely the case, and if necessary, any impacted applications can be easily whitelisted so they still work.
Minimal (If Any) Pain, Much to Gain
As we alluded to above, Windows has set certain expectations for installed software. A proper installation places executables in the Program Files folder, and the running applications then place data in AppData or sometimes in a temporary folder. That’s why the GPO approach rarely breaks anything, and given the remote chance that it may impact an oddball application (which, as noted, can be easily whitelisted), the protection more than makes up for any slight inconvenience.
Criminals are crafty. We’re not going to say implementing this GPO makes your systems ransomware- proof. We will say, though, that in our experience with clients, we’ve found it to be extraordinarily effective.
We’re happy to provide these sorts of tips and information to help you protect your data, your systems — and thereby, your entire business. Any network administrator with knowledge of Group Policy Objects can implement this important defensive measure for you. That said, if you’d like to learn more about this or other defensive measures, schedule a consultation with one of our security engineers today.