Disable PowerShell and other features of the fight against Malware. Part I

It seems that not so long ago, about 2015, we began to hear about hackers who did not use malicious software inside the perimeter of the attacked target. And they used what was at hand - these were the various tools that were on the target site. It turned out to be an ideal way to do your “dirty business” without raising unnecessary “noise”.



Nowadays, this approach has gained momentum and has become mainstream, primarily due to the abundance of ready-made hacker tools, such as PowerShell Empire.



We already wrote about how PowerShell, when it is complemented by PowerView, becomes a powerful information provider for hackers (all this wisdom is collected in our collection, which you should read as soon as possible).



Of course, any tool can be used both for good and for bad, so I don’t think to imply that PowerShell was created to make life easier for hackers.

But just as you would not leave a heavy-duty bolt cutter next to the padlock, you probably don’t want to allow, or at least make it as difficult as possible for hackers to get their hands on PowerShell.

')

This in turn brings up a big topic in the cybersecurity world: application access restriction, also known as white and black access lists. The general idea is that the operating system knows and strictly controls which applications can be run by the user, and which ones can not.



For example, being a homo blogus, I usually need some basic tools and applications (as well as a warm place where I can sleep at night), and I can perfectly live without PowerShell, netcat, psexec, and all the other commands that I told in previous posts. The same applies to most employees in companies, and therefore a qualified IT professional should be able to compile a list of applications that are safe to use.



In the Windows world, it is possible to use rules for executing applications using special restrictive software usage policies, and more recently AppLocker.



However, before we move on to these advanced ideas, let's try two very simple solutions, and then see what is wrong with them.

ACL and other simplifications

We often think of Windows ACLs that they use to control access to readable content. But they can also be applied to executable files — that is, .exe, .vbs, .ps1, and others.



I returned to the Amazon Web Services cloud, where I have a Windows domain for the mythical and once legendary company Acme, and did work with the ACL there to demonstrate some access restrictions.







PowerShell .exe, any system administrator can easily tell you is in C: \ Windows \ System32 \ WindowsPowerShell \ v1.0. I moved to this folder, called up its properties, and instantly limited the rights to run PowerShell into 2 main groups: “Domain Admins” and “Acme-SnowFlakes”, groups of experienced Acme users.



I reloaded to the server, like Bob, my role at Acme, and tried to call PowerShell. Results below.







In practice, you could probably come up with a script - why not use PowerShell to automate this ACL setup process for all laptops and servers in small and medium-sized companies.



This is not a bad decision.



If you do not like the idea of ​​changing the ACL on executable files, PowerShell offers its own means of limiting. As a user with admin rights, you can use anything you like, but the simplest is the built-in Set-ExecutionPolicy cmdlet.



This is not so "clumsy" solution, as the installation of ACL. For example, you can restrict PowerShell to work only interactively — using the Restricted parameter — so that it will not execute PS scripts that may contain hacker malware.



However, it will also block PowerShell scripts run by your IT specialists. To allow approved scripts, but disable malicious hacker scripts, use the RemoteSigned parameter. Now PowerShell will run only signed scripts. Administrators, of course, will have to create their own scripts and then sign them using verified credentials.



I will not go into details on how to do this, mainly because it is so easy to get around. Someone here in the blog described as many as 15 ways to circumvent security restrictions in PowerShell.



The easiest is using the Bypass parameter in PowerShell itself. Yes! (see below).







Looks like a security hole, eh?



So there are several major vulnerabilities in PowerShell. This is by the way and understandable, since it is, after all, just a software shell.



But even the constraint approach at the ACL level has its own fundamental problems.

If hackers weaken their philosophy, they can easily download, say, using the Remote Access Trojan (RAT) - their own copy of PowerShell. And then run it directly, easily avoiding permission restrictions with local PowerShell.

Software Use Restriction Policies

These major security holes (like many others) always accompany the consumer class of operating systems. This led the OS researchers to come up with a safe operating system that would have enough power to control what could be running.



In the Windows world, these forces are known as program use restriction policies (SRPs) - for familiarization, see this - they are configured through the Group Policy editor.

With their help, you can control which applications can be launched based on the file extension, path names, and whether the application has been digitally signed.



The most effective, albeit the most painful approach, is to ban everything, and then add there applications that you really need. This is known as whitelisting.



We will analyze this in more detail in the next section.



In any case, you need to run the policy editor, gpEdit, and go to the Local Computer Policy> Windows Settings> Security Settings> Software Restriction Polices> Security Levels policy. If you click on “Disallowed”, then you can make it the default security policy - do not run any executable files!







Whitelist: disable by default, and then add allowed applications to “Additional Rules (Additional Rules)”.



This is more like scorched earth tactics. In practice, you will need to enter “additional rules” to add back the allowed applications (with their names and paths). If you exit PowerShell, you actually disable this tool in place.



Unfortunately, you cannot fine-tune the rules for restricting the use of programs based on individual groups or users. Pancake!



And now this logically leads us to Microsoft’s latest security achievement, known as AppLocker, which has its unique features to allow the application to open. Talk about it next time.