Microsoft developed Windows PowerShell for task automation and configuration management. It is based on.NET framework; while it includes a command-line shell and a scripting language. It does not help users to automate, but it also rapidly solves complex administration tasks. Despite that, many users often believe that PowerShell is a tool used by hackers for security breaches. Unfortunately, it is true that PowerShell is widely used for security breaches. Due to this, users with less or no technical knowledge often deactivate PowerShell. However, the reality is that the PowerShell Security approach can provide the best protection against security breaches at the enterprise level.
David das Neves, Premier Field Engineer for Microsoft Germany mentions in one of his posts that the PowerShell Security approach is a powerful way to set up the security at the enterprise level. In fact, PowerShell is one of the most used languages on GitHub, according to Programming Language Ranking chart created by RedMonk.
Understanding PowerShell security
Windows PowerShell is being used by many IT administrators across the globe. It is a task automation and configuration management framework from Microsoft. With its help, administrators can perform administrative tasks on both local and remote Windows systems. However, recently, a few organizations have been avoiding using it; especially for remote access; suspecting security vulnerabilities. To clear this confusion around the tool, Microsoft Premier Field Engineer, Ashley McGlone published a blog that mentions why it is a safe tool and not a vulnerability.
Organizations are considering PowerShell as vulnerability
McGlone mentions some of the recent trends in the organizations concerning this tool. Some organizations are forbidding the use of PowerShell remoting; while elsewhere InfoSec has blocked remote server administration with it. He also mentions that he constantly receives questions around PowerShell Remoting security. Multiple companies are restricting the tool’s capabilities in their environment. Most of these companies are worried about tool Remoting, which is always encrypted, single port 5985 or 5986.
PowerShell security best practices
McGlone describes why this tool is not a vulnerability – but on the other hand, is very safe. He mentions important points such as this tool is a neutral administration tool, not a vulnerability. The tool’s remoting respects all Windows authentication and authorization protocols. It requires local Administrator group membership by default.
He further mentions why the tool is safer than companies think:
“The improvements in WMF 5.0 (or WMF 4.0 with KB3000850) make PowerShell the worst tool of choice for a hacker when you enable script block logging and system-wide transcription. Hackers will leave fingerprints everywhere, unlike popular CMD utilities”.
Because of its powerful tracking features, McGlone recommends PowerShell as the best tool for remote administration. The tool comes with features that allow organizations to find the answer to the questions like who, what, when, where, and how for activities on your servers.
He further gave the links to resources to learn about securing this tool and using it on an enterprise level. If the information security department in your company wants to learn more about this tool, McGlone provides a link to PowerShell Remoting Security Considerations. This is new security documentation from the PowerShell team. The document includes various informative sections such as what is Powershell Remoting, its default settings, process isolation and encryption, and transport protocols.
The blog post mentions several sources & links to learn more about PowerShell. You can get these sources, including links to the WinRMSecurity website and a white paper by Lee Holmes here on TechNet Blogs.
Windows PowerShell Security at Enterprise level
Before setting up Windows PowerShell Security, it is necessary to know the basics of it. Users must use the latest version of Windows PowerShell. The user must note here that PowerShell Security must be set with the latest version of Windows PowerShell. If it is a lower version (like PowerShell Version 2) can do more harm than good. Hence, it is advised that users must get rid of PowerShell version 2.
Apart from the latest version of Windows PowerShell, users must also opt for the newest version of OS. To set up the PowerShell Security, Windows 11 or Windows 10 are the most compatible operating system. Windows 11/10 comes with many security features. Hence, it is recommended that users should migrate their older Windows machines to Windows 11/10 and evaluate all the security features which can be used.
ExecutionPolicy: Many users don’t opt for the PowerShell Security approach and use the ExecutionPolicy as a security boundary. However, as David mentions in his post, there are more than 20 ways to surpass the ExecutionPolicy even as a standard user. Therefore users should set it via GPO such as RemoteSigned. ExecutionPolicy may prevent some hackers from using PowerShell scripts from the internet, but it is not a completely reliable security setup.
Factors to be considered in PowerShell Security approach
David mentions all the important factors to be considered when setting up PowerShell Security at the enterprise level. Some of the factors that are covered by David are as follows:
- PowerShell Remoting
- Securing Privileged Access
- Modernizing Environment
- Whitelisting / Signing / ConstrainedLanguage / Applocker / Device Guard
- Logging
- ScriptBlockLogging
- Extended Logging / WEF and JEA
For more detailed information on PowerShell Security setup, read his post on MSDN Blogs.
