...
There is never enough restrictions in place. I prefer to go all the way using unconventional methods, which are not known to malware coders, like disabling bash malware simply by preventing it from being enabled using DISM. If you look at how malware works (like the scary SeTcbPrivilege), it checks for restrictions, etc and once it elevates to system rights, it will change settings to whatever it wants to.
15 Ways to Bypass the PowerShell Execution Policy
That is right. But, there is not a good idea to concentrate on how to mitigate the malware that has been allowed to run on the system (
especially with elevation). Of course, it is possible but very ineffective and the system is close to unusable one. Such protections like SRP, blocking or restricting scripts, blocking sponsors, blocking remote access, blocking SMB, using forced SmartScreen, etc., are directed in the first place to prevent malware from running on the system or downloading the payloads. Some elements of such protection will work also as malware mitigation, but this is a secondary purpose.
By the way, all tricks from
15 Ways to Bypass the PowerShell Execution Policy and some more can be prevented by built-in Windows security (blocking execution of scripts + PowerShell set to Constrained Language mode + blocking the PowerShell sponsors). The way such security works can be seen when analyzing
@askalan tests from Malware Vault (samples) threads (21.09 - 14-10-2017). The system was protected against all malware samples (even without blocking powershell.exe) because they could not run or download malicious files.
The tweaks used by
@TairikuOkami or included in Hard_Configurator, are very effective against malware in the wild. They can be bypassed (like any security) in the targetted attacks.