shmu26

Level 85
Verified
Trusted
Content Creator
Yes, except maybe a few updates for 3rd party vendors (AMD, Intel, NVIDIA, etc.). I am not sure about updates from Microsoft Store, but this should not be the issue.
None of this should be an issue if powershell is blocked by SRP, because the updates will be started by service and run with elevated rights. Correct?
 

shmu26

Level 85
Verified
Trusted
Content Creator
If "restricted" is the default Windows setting for powershell, and this blocks execution of all scripts, how is powershell commonly abused? Does malware first need to modify the execution policy? But how can it do that, without running a script? Sounds like catch 22.
 

Windows_Security

Level 23
Verified
Trusted
Content Creator
@Andy Ful I had not thought about adding startup folders to ' protected folders" feature of WD anti-ransomware protection: brilliant thanks now I can close the basic user holes in a easy way with protected folders whitelisting :emoji_ok_hand:(y)
 

Windows_Security

Level 23
Verified
Trusted
Content Creator
If "restricted" is the default Windows setting for powershell, and this blocks execution of all scripts, how is powershell commonly abused? Does malware first need to modify the execution policy? But how can it do that, without running a script? Sounds like catch 22.
Well as Andy mentioned and the read up explains, it is also advised to put powershellitself in constrained languagemode, because powershell is part of Windows (you don't need to run powershell.exe that is what Andy mentioned when suggestion the option to allow Windows Update direct acces to System.Management.Automation.dll when disabling powershell.exe with WD exploit options)

Just enable the powershell settings of SysHardener, when you enable SRP through Hard Configurator, you have access to powershell sufficiently caged as far as I know, without breaking Windows functionality needed for daily operations and updates. Maybe other members know of blackhat or darkweb posts which explian how to evade all of them.
 

shmu26

Level 85
Verified
Trusted
Content Creator
Well as Andy mentioned and the read up explains, it is also advised to put powershellitself in constrained languagemode, because powershell is part of Windows (you don't need to run powershell.exe that is what Andy mentioned when suggestion the option to allow Windows Update direct acces to System.Management.Automation.dll when disabling powershell.exe with WD exploit options)

Just enable the powershell settings of SysHardener, when you enable SRP through Hard Configurator, you have access to powershell sufficiently caged as far as I know (I don't know of succesfull blackhat tricks to bypass these hardening tips), without breaking Windows functionality needed for daily operations and updates.
Thanks. Just trying to understand how things work. I thought that side-loading powershell dlls is an advanced and relatively unusual exploit technique, whereas the common variety of "live off the land" malware simply executes a powershell script. Is this wrong?
 

Andy Ful

Level 60
Verified
Trusted
Content Creator
None of this should be an issue if powershell is blocked by SRP, because the updates will be started by service and run with elevated rights. Correct?
Not always, unfortunately. I had those issues with NVIDIA updates (on Windows 7) which were blocked by SRP. They were triggered after normal Windows Updates at the boot time, probably via the registry key. But, the problem was simply solved by executing the update installer via "Run As SmartScreen".
 

shmu26

Level 85
Verified
Trusted
Content Creator
Not always, unfortunately. I had those issues with NVIDIA updates (on Windows 7) which were blocked by SRP. They were triggered after normal Windows Updates at the boot time, probably via the registry key. But, the problem was simply solved by executing the update installer via "Run As SmartScreen".
I see. So in that case, disabling child processes will result in the same problem.
 

Windows Defender Shill

Level 7
Verified
While being a strong advocate of this setting, I can confirm I've seen computers utilizing it still be infected in the real world. I believe it was through an email client, but can't say for sure. This person wasn't torrenting or installing apps through USBs, but somehow still ended up with malware.

That being I said, I still utilize it on my own machine as a little extra defense against a deceptive file
 

Andy Ful

Level 60
Verified
Trusted
Content Creator
Excellent article. That was also my first reading when I opened the thread:
Tutorial - How do you secure PowerShell?
.
@Windows_Security and @shmu26,
From Windows 7, PowerShell has by default execution policy set to Restricted. This is not a security feature, because almost all malicious scripts usually bypass it via the simple switch in the PowerShell commandline.
.
With NVT SysHardener there is also an option to set more restrictive settings
The SysHardener option "Restrict PowerShell (v3+) to Constrained Language Mode" is slightly weaker as standard user than Constrained Language Mode applied in SRP. This can be covered by adding the second option "Disable PowerShell Script Execution (Windows 7+)" that is included also in Hard_Configurator. In SysHardener both options should be ticked.
PowerShell 2.0 is disabled in Windows 10 (it can be re-enabled by the user + some installations are required).
 

shmu26

Level 85
Verified
Trusted
Content Creator
If "restricted" is the default Windows setting for powershell, and this blocks execution of all scripts, how is powershell commonly abused? Does malware first need to modify the execution policy? But how can it do that, without running a script? Sounds like catch 22.
To answer my own "noob" question, this article explains 15 bypasses to the "restricted" policy.
15 Ways to Bypass the PowerShell Execution Policy
 

Andy Ful

Level 60
Verified
Trusted
Content Creator
@Andy Ful I had not thought about adding startup folders to ' protected folders" feature of WD anti-ransomware protection: brilliant thanks now I can close the basic user holes in a easy way with protected folders whitelisting :emoji_ok_hand:(y)
Although, you will have to add shortcuts manually or disable Ransomware protection before installation.
 

Andy Ful

Level 60
Verified
Trusted
Content Creator
While being a strong advocate of this setting, I can confirm I've seen computers utilizing it still be infected in the real world. I believe it was through an email client, but can't say for sure. This person wasn't torrenting or installing apps through USBs, but somehow still ended up with malware.

That being I said, I still utilize it on my own machine as a little extra defense against a deceptive file
What setting? (Please, do not answer if it is 'Allow apps from the store only' from the first post.)
If so, then it is understandable, because the above setting does not protect against executable payloads. So, the user could be easily infected by opening the malicious document, that downloaded and executed the executable payload. If the same executable payload was downloaded via the web browser, then it would be blocked.
 
Last edited:

Windows_Security

Level 23
Verified
Trusted
Content Creator
I see. So in that case, disabling child processes will result in the same problem.
By disabling child processes, you will get an error when starting Powershell, so you effectively block it :)
Although, you will have to add shortcuts manually or disable Ransomware protection before installation.
I added [USER]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs to the protected folders option, now Basic User as default level is OK (with the advantage of simple right click install as admin and all program shortcuts and microsoft consoles working)
1533482628456.png
 
Last edited:

Andy Ful

Level 60
Verified
Trusted
Content Creator
By disabling child processes, you will get an error when starting Powershell, so you effectively block it :)

I added [USER]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs to the protected folders option, now Basic User as default level is OK (with the advantage of simple right click install as admin and all program shortcuts and microsoft consoles working)
View attachment 194512
You have to add also:
c:\ProgramData\Microsoft\Windows\Start Menu
c:\UsersVeilig Internetten\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch
 
Last edited:

Andy Ful

Level 60
Verified
Trusted
Content Creator
By disabling child processes, you will get an error when starting Powershell, so you effectively block it :)
Indeed, when blocking child processes in powershell.exe, its execution will fail with an error. But, not in the case of powershell_ise.exe. So probably, the error for powershell.exe is a bug, that can be corrected by Microsoft in the future.
 
Top