Disabling PowerShell and other ways to combat Malware, Part II
This article is part of the series "Turning off PowerShell and other ways to combat Malware."
See also:
• Part I
• Part II
• Part III
')
The list of allowed applications is not a joke. First, you have to start with a clean slate, and then carefully add safe applications that you know and trust. This is what we began to develop the idea of a program use restriction (SRP) policy last time.
As you remember, we first cleared the “clearing”, by default disabling the execution of applications. In the additional rules section, then I started adding rules for applications that were important to me.
Only those applications that you will ever need!
Obviously, this can be a bit of a tedious task, so Microsoft kindly provided two default rules: one to allow applications to run in the Program Files folder and the second to allow executable files in the Windows system directory.
But this is also not very convenient, because then you will have to blacklist the applications that you do not need.
In any case, when a user launches an unapproved application or a hacker tries to download some malicious programs that are not on the whitelist, SRP will prevent this. That's what happened when I tried to start PowerShell, which was not on my whitelist, from the good old cmd shell, which is on the list:
Damn you SRP software restriction policy!
100% Security
To be ideologically pure, you should not use the Windows default policy rules. Instead, you have to start from scratch and do all the hard work figuring out which applications you use and you really need.
However, to help you overcome this obstacle, Microsoft suggests in the TechNet article to include SRP logging, where the recording is made, every time the SRP evaluates the application. We will need to include the following registry entry and set the location of the log file:
1. "HKLM \ SOFTWARE \ Policies \ Microsoft \ Windows \ Safer \ CodeIdentifiers"
2
3. String value: LogFileName, <path to log file>
Here is an example of such a journal from my AWS test environment.
SRP operation log file.
Then you will need to look at this log, as well as possibly interview your users or discuss it with other IT administrators. Suppose that you ended up with a list of allowed applications (besides PowerShell itself) that you think most of your users need. Well, in the end, you can use the Group Policy Management Console (GPMC) to publish these rules in the domain.
In theory, you should be able to drag and drop the rules via drag-and-drop from the Local Policy Editor console to the GPMC domain policy management. I could not do this in my AWS environment.
Instead, I had to recreate all the rules directly in the Group Policy Editor (below) and then allowed him to do the rest of the work, “spilling” these policies across the domain — in my case, the Acme domain.
Real Magic!
You can read about it here.
Take a look at AppLocker
Let's go back to the PowerShell issue again. We cannot live without it, but the "evil" hackers also love it as an excellent tool for covertly researching the network after its introduction inside.
And if I put it on my whitelist, then even with some of the built-in PowerShell protection that I mentioned in my last post, there are still so many ways to get around all these security measures that you shouldn’t even try.
It would be nice if the SRP rules allowed the creation of allowed lists selectively based on the membership of users and groups in Active Directory. In other words, disable in PowerShell, except if you are an IT administrator, for example, who is in a special authorized PowerShell group AD.
This, however, is not in the SRP, as it does not support this level of detail!
However, starting with Windows 7 (and Windows Server 2008), Microsoft abandoned SRP and introduced more powerful AppLocker features. It is very similar, but at the same time it has the ability to filter at the user or group level.
We will talk about AppLocker and some of its benefits in the final post of this series. In any case, you can easily find it next to the SRP policies in the Application Management Policy section of the GPMC Group Policy Editor.
For my Acme environment, I created a rule that allows PowerShell only for Acme-VIPS users, for a small group of experienced employees. See below where I started configuring this using the AppLocker configuration wizard dialog:
PowerShell is undoubtedly an important and useful tool, so you need to weigh all the risks of selectively turning it on via AppLocker - I’m not afraid of the word, perform a risk assessment.
At the same time, you (of course) must have secondary controls, such as, hmm, User Behavior Analysis (UBA) , which will allow you to protect yourself even if the administrators of your administrators are completely compromised, for example, everything is allowed their logins by intruders or insiders.
In the meantime, let's leave a description of the useful functions of AppLocker, as well as my final conclusions on the subject of white lists until the next post.
See also:
• Part I
• Part II
• Part III
')
The list of allowed applications is not a joke. First, you have to start with a clean slate, and then carefully add safe applications that you know and trust. This is what we began to develop the idea of a program use restriction (SRP) policy last time.
As you remember, we first cleared the “clearing”, by default disabling the execution of applications. In the additional rules section, then I started adding rules for applications that were important to me.
Only those applications that you will ever need!
Obviously, this can be a bit of a tedious task, so Microsoft kindly provided two default rules: one to allow applications to run in the Program Files folder and the second to allow executable files in the Windows system directory.
But this is also not very convenient, because then you will have to blacklist the applications that you do not need.
In any case, when a user launches an unapproved application or a hacker tries to download some malicious programs that are not on the whitelist, SRP will prevent this. That's what happened when I tried to start PowerShell, which was not on my whitelist, from the good old cmd shell, which is on the list:
Damn you SRP software restriction policy!
100% Security
To be ideologically pure, you should not use the Windows default policy rules. Instead, you have to start from scratch and do all the hard work figuring out which applications you use and you really need.
However, to help you overcome this obstacle, Microsoft suggests in the TechNet article to include SRP logging, where the recording is made, every time the SRP evaluates the application. We will need to include the following registry entry and set the location of the log file:
1. "HKLM \ SOFTWARE \ Policies \ Microsoft \ Windows \ Safer \ CodeIdentifiers"
2
3. String value: LogFileName, <path to log file>
Here is an example of such a journal from my AWS test environment.
SRP operation log file.
Then you will need to look at this log, as well as possibly interview your users or discuss it with other IT administrators. Suppose that you ended up with a list of allowed applications (besides PowerShell itself) that you think most of your users need. Well, in the end, you can use the Group Policy Management Console (GPMC) to publish these rules in the domain.
In theory, you should be able to drag and drop the rules via drag-and-drop from the Local Policy Editor console to the GPMC domain policy management. I could not do this in my AWS environment.
Instead, I had to recreate all the rules directly in the Group Policy Editor (below) and then allowed him to do the rest of the work, “spilling” these policies across the domain — in my case, the Acme domain.
Real Magic!
You can read about it here.
Take a look at AppLocker
Let's go back to the PowerShell issue again. We cannot live without it, but the "evil" hackers also love it as an excellent tool for covertly researching the network after its introduction inside.
And if I put it on my whitelist, then even with some of the built-in PowerShell protection that I mentioned in my last post, there are still so many ways to get around all these security measures that you shouldn’t even try.
It would be nice if the SRP rules allowed the creation of allowed lists selectively based on the membership of users and groups in Active Directory. In other words, disable in PowerShell, except if you are an IT administrator, for example, who is in a special authorized PowerShell group AD.
This, however, is not in the SRP, as it does not support this level of detail!
However, starting with Windows 7 (and Windows Server 2008), Microsoft abandoned SRP and introduced more powerful AppLocker features. It is very similar, but at the same time it has the ability to filter at the user or group level.
We will talk about AppLocker and some of its benefits in the final post of this series. In any case, you can easily find it next to the SRP policies in the Application Management Policy section of the GPMC Group Policy Editor.
For my Acme environment, I created a rule that allows PowerShell only for Acme-VIPS users, for a small group of experienced employees. See below where I started configuring this using the AppLocker configuration wizard dialog:
PowerShell is undoubtedly an important and useful tool, so you need to weigh all the risks of selectively turning it on via AppLocker - I’m not afraid of the word, perform a risk assessment.
At the same time, you (of course) must have secondary controls, such as, hmm, User Behavior Analysis (UBA) , which will allow you to protect yourself even if the administrators of your administrators are completely compromised, for example, everything is allowed their logins by intruders or insiders.
In the meantime, let's leave a description of the useful functions of AppLocker, as well as my final conclusions on the subject of white lists until the next post.
Source: https://habr.com/ru/post/349972/
All Articles