Use Windows 10 build-in (anti)execution options

[shmu26]

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?

 

[Windows_Security]

This is a nice readup. PowerShell Security: PowerShell Attack Tools, Mitigation, & Detection – Active Directory Security

With NVT SysHardener there is also an option to set more restrictive settings

 

[shmu26]

This is a nice readup. PowerShell Security: PowerShell Attack Tools, Mitigation, & Detection – Active Directory Security

View attachment 194505

With NVT SysHardener there is also an option to set more restrictive settings
View attachment 194506

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]

@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_handy)

 

[Windows_Security]

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]

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]

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]

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]

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]

This is a nice readup. PowerShell Security: PowerShell Attack Tools, Mitigation, & Detection – Active Directory Security

View attachment 194505


View attachment 194506

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]

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]

@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_handy)

Although, you will have to add shortcuts manually or disable Ransomware protection before installation.

 

[Andy Ful]

I see. So in that case, disabling child processes will result in the same problem.

Disabling the child processes of what?

 

[Andy Ful]

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.

 

[shmu26]

Disabling the child processes of what?

Of powershell.

 

[Andy Ful]

Of powershell.

This can be the less important issue, because PowerShell uses cmdlets for many tasks which do not spawn child processes. Child processes are more often present when the malicious script is using PowerShell.

 

[Windows_Security]

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)

 

[Andy Ful]

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

 

[Andy Ful]

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.

 

[Windows_Security]

You have to add also:
c:\ProgramData\Microsoft\Windows\Start Menu
c:\UsersVeilig Internetten\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch

Thx done (forgot the second one, first one is protected by UAC, but this is an improvement)