Ondrej Sevecek's English Pages

PowerShell provides a great tool for hackers running arbitrary netfx or even win32 code, which can also be download in a source code textual form from internet and in the worst case just copy-pasted into a running PowerShell command line window withouth leaving any permanent trace or evidence on the user machine.

Preventing unwanted PowerShell scripts or code snippets on user environements (workstations as well as RDS, RemoteApp and RDP) becomes more challenging because administrators often need to run administrative scripts or program installations on the same machines.

If you want to disable some powershell functionality, I can imagine the following aproaches, though only the AppLocker method seems to me safe enough and the most flexible:

• local execution policy - configuring it by Set-ExecutionPolicy or by changing registry settings in HKLM or HKCU directly. You may want to allow only digitally signed scripts (AllSigned) or block all scripts (Restricted) at all. Although this can be applied per computer (HKLM) or per user (HKCU), it is not too effective way. When user starts powershell.exe with -ExecutionPolicy Bypass parameter, it overrides the local registry settings for the duration of the script or command.
• Group Policy Object based execution policy - you can enforce the settings from Administrative Templates - Windows Components - Windows PowerShell - Enable script execution. With this you can enforce the AllSigned policy per machine (computer configuration) or per user (user configuration part of GPO), but you cannot block all scripts. Although this GPO setting takes precedence even over the -ExecutionPolicy parameter of powershell.exe, the other parameters -Command and -EncodedCommand still ignore the execution policy at all. The most effective hacker's workaround for execution policy is also the simplest one - just copy-paste the powershell source code into an open powershell or ISE command line. This leads me to rather block powershell.exe from running at all instead of blocking PS1 and PSM1 script files.
• RemoteApps running on a remote RDS server - it might seem like a good idea to let the users start only selected "safe" and explicitly published applications in the form of RDP RemoteApps so that they cannot start anything else in the remote desktop session. Don't be fooled. If the RemoteApp program uses the standard Open File or Save As explorer's dialog box, malicious user can start another apllication from it. They can just type the executable path of C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe into the address bar or right click the EXE file and select the Open menu item. Take a look at the following screenshot:

• Software Restriction Policies (SRP) blocking of poweshell.exe using GPO - this technology exists since Windows XP on all Windows editions which offers easy usage. The settings are available in both the computer configuration and user configuration parts of a GPO so that you can configure the setting per-machine or per-user for only specific user groups. If you do not go for white-listing the safe applications and must use only black-listing of powershell it will have only a limited effect though. You can block the exact path of C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe and C:\windows\system32\WindowsPowerShell\v1.0\powershell_ise.exe but the users would be able to copy the executables elsewhere, such as their desktop folder. You can block just the powershell.exe and powershell_ise.exe but if the users rename the copied files, they will run anyway.

• AppLocker blocking the poweshell.exe signed executable by publisher using GPO - this is the most powerful way by my experience. Although AppLocker (Appllication Control Policies) is available on server editions and Enterprise workstation editions of Windows, it is the best solution. Even with only black-listing the powershell executables it could be quite efficient. Especially when combined with a process auditing and monitoring. You find the settings in computer configuration part of GPO only, but you can apply its rules to user groups anyway. To block powershell and ISE executables you use the Publisher rule without specifying file version, but keeping the file name and publisher certificate. This way not even renaming helps the attacker to start the program while modifying the executable is not possible due to its digital signature.

Do not forget about monitoring. You can enable security auditing of the Detailed tracking - audit process creation through GPO. If you also have a SCOM (System Center Operations Manager) deployment, you can define some rules or monitors to trigger alerts if powershell executables are started.

Even for members of local Administrators it would be difficult to wreck security auditing prior to starting powershell or downloading and starting any complex tool from internet.