Windows Group Policy tends to get overlooked by most Administrators. Typically, you visit this policy when you first set up a domain—which for many companies is well beyond the first day you start using Windows. By the time you get around to re-visiting Windows Group Policy, most of the applications, users, and groups are already in place.
What’s not very well understood is the Windows Group Policy permissions model that allows attackers to manipulate your system with Ransomware even without any usernames, passwords, or you authorizing their applications.
As a vCISO one of the first and most important policies I try to advise clients on is a Software Restriction Policy. I believe strongly that many Administrators of Microsoft PCs overlook this tool in combating malware because they believe it will break applications and brick machines. They may also think taking away “Administrator” rights for users means they have disallowed the installation and usage of software by those user accounts (even if tricked by hackers).
This is simply not the case. Software on Windows is intended to be run and to run other programs without the user’s credentials involved (Admin or otherwise). A simple example is Microsoft Word. If you were to download a new copy of Word and wanted to install it into the Program Files directory you would first be asked if you are an Administrator and to enter an Admin password. You know, this pop-up thing:
That’s just the install. Running a program is totally different.
If you open Word, the program runs from a directory and it may also chose to run other programs in other directories (Macros, PDF Converters, GotoMeeting, Teams, etc.) While this is awesome for productivity it demonstrates how hackers use the default “Unrestricted” policy on Windows that allows you to run executables outside of the Program Files/Windows folders all you want, with whatever user and whatever program (“unrestricted,” indeed!)
So, what’s that got to do with malware? Well, if you are an attacker and a user opens a Word document you sent them, you can now launch any program you wish without needing additional permissions. This includes some fun activities that give you complete access to the operating system without the need for a password or to install other programs.
My best example is a horrifying Trojan known as Trickbot/EMOTET, which allows a malicious actor to deploy any variant of Ransomware they like without an AV being able to stop it.
The Trojan is an .EXE file. Sending it directly to a user would be tactless. Who would click on that right? (Right?) But in order to make the most of trained staff and plenty of inboxes an attacker will add just a simple extra step: a Word document with an embedded macro that downloads and runs the file automatically.
Conflicting Views
Right now is usually when I get the most push back on the strategy. You see, vendors of security software have for years positioned their products as “Smart Enough” to catch this behavior. Don’t worry which ones either—they are all guilty of it. Email Anti-Spam, Anti-Virus, Firewalls, you name it. Put “Next-Gen” in front of the name and they’ll go on about how many times their solution stopped such behaviors. They conveniently leave out that no matter who they are or the technique they use they don’t work 100% of the time. So, let’s talk about the times they don’t: because that’s when the software restriction policy is going to save you.
Assuming the Word document is opened by an apologetic, well-meaning, hard-working member of your staff like your vCISO (because we’re human too), what happens?:
- Anti-Spam: Reads the Word document and sees a few macros about copying files locally. No big deal. Not spam. English is good. No hyperlinks. The file makes it to the inbox. FAIL.
- Firewall: Word document with some new macro code that doesn’t match anything we’ve seen before or the program libraries from previous attacks. We’ll let that go through as well. FAIL.
- Macro copies the BITS.exe program and creates a few scripts in AppData. AV is cool with this because there’s no virus, these are all just Windows programs. FAIL.
- BITS then copy a new Trojan from a whitelisted site like Microsoft.com. Firewall sees BITS going to Microsoft just like a Windows update. Nothing to block. FAIL.
- Trojan no signature, different behaviors, tested against all modern AV programs, and spreads to all your machines without so much as an alert. FAIL.
Everything after step 3 was avoidable. Not with a product, but with a policy that disallowed any of the executables used (the macros, the new .EXEs, the folders Word tried to run new programs in).
Our customers know this. But you might not. So hopefully this was a helpful example of one of the many strategies we use to secure you with our vCISO advice. Read on for the two most common questions I get about this.
FAQ:
That’s great, if I have this do I need AV or an MDR service?
Anti-virus will block popular campaigns but is not fool proof or 100%. It lowers risks of infection but does not eliminate them. Restricting folders provides MDR providers like us a simpler structure to look for bad behavior. These restrictions help us find and remove threats easier, which can be run all from memory (fileless) or through your programs (injection). You still want AV tools and an MDR service working for you (and us!) to catch and remove the remaining percentage of threats that do get through the automation.
What about Mac and Linux?
Macintosh and Linux have similar policies but don’t allow programs to run other programs the same way as Windows. Just like your phone they have prompts when software attempts to access certain directories it shouldn’t. You know, this:
