- Secure DNS requests over HTTPS (DoH) in Windows 10/11 - Thu, Jul 22 2021
- Microsoft Windows 365: Fixed-price cloud PC with simplified deployment - Fri, Jul 16 2021
- Deactivate Windows 10 widget "News and interests" with Group Policy - Thu, Jul 15 2021
PowerShell offers almost unlimited access to the resources of a Windows computer and can automate numerous applications, such as Exchange. Users aren't limited to the many modules and cmdlets, but can also integrate .NET classes, Windows APIs, and COM objects. These capabilities are particularly dangerous in the hands of attackers.
Since many versions of Windows Server, Microsoft avoids activating any roles and features on a freshly installed machine in order to minimize the attack surface. On such a locked-down system, users must explicitly add all required services.
Lax default configuration of PowerShell ^
However, with PowerShell, the full range of functions is available from the start on every Windows PC, if you ignore the "protection." by a restrictive execution policy. It is not recommended to leave the machine in this state.
It's not only malicious PowerShell experts who can exploit the full potential of a script that you should fear. In fact, even basic knowledge is sufficient to penetrate systems with the help of various hacking tools.
Hacking tools for PowerShell ^
You might assume that your computers are well protected by virus scanners that detect and block these hacking tools. Windows Defender, for example, intervenes after the download and quarantines the scripts.
However, in contrast to binary files, scripts can be changed quite easily to fool signature-based recognition. For example, you can copy Invoke-Mimikatz from the browser window and paste it into an editor such as PowerShell_ISE to experiment with the code.
This blog post by Carrie Roberts demonstrates how to outwit most virus scanners by searching and replacing a few significant code snippets. The technique discussed there may not be up to date, but a bit of experimenting will probably reveal how virus scanners detect this script. Otherwise, various AMSI-Bypasses can help you to overwhelm Windows Defender.
General blocking of PowerShell ^
To prevent such threats, many companies take a drastic step and disable PowerShell altogether. In centrally managed environments, blacklisting with AppLocker or the Software Restriction Policies (SAFER) is an effective solution. If you decide to use SAFER, you create two new hash rules and connect them to powershell.exe and powershell_ise.exe. For the security level, choose Not allowed. If you block the programs at the user level, admins can be excluded.
This approach has two disadvantages. First, it can be an obstacle to system administration because PowerShell has become an indispensable tool for most admins. For example, PowerShell logon scripts that are executed in the security context of a user will no longer work.
Circumvention through alternative shells ^
A more serious issue, however, is that PowerShell comprises more than just powershell.exe or power-shell_ise.exe and therefore cannot be permanently blocked by denying access to these two files. Rather, it is a system component (System.Management.Automation) that cannot be removed and can be used by various runspaces. Attackers could thus access PowerShell from any of their own programs. It is therefore no surprise that shells already exist that can be integrated into your own code or that can be executed directly. Among them are p0wnedShell or PowerOPS.
In addition, numerous versions of PowerShell 6 and 7 are available for download in ZIP format, which can easily be unpacked into a directory and executed. Frequent previews of PowerShell 7 would keep admins busy because they always have to create new rules to cover all these versions.
Last but not least, another workaround is to compile PowerShell scripts into executable files. They are also not dependent on powershell.exe and must be blocked by separate SAFER or AppLocker rules
Securing PowerShell with integrated mechanisms ^
Instead of completely banishing PowerShell without achieving real security, it makes more sense to use its security features. These were further improved with version 5, so that you should update PCs to the latest version of PowerShell.
It is also highly recommended that PowerShell 2.0 be removed; it is still preinstalled as an optional feature and can be uninstalled in Windows 8.1 and Server 2012 or higher. With this old version, all major restrictions for PowerShell can be circumvented.
One of the key security mechanisms of Windows PowerShell is the Constrained Language mode, which disables several dangerous features. This language mode is particularly effective when used in conjunction with application whitelisting.
Besides the means to prevent the abuse of PowerShell, there are also functions to track down suspicious and unwanted activities. These include recording all executed commands in log files (transcription) as well as the newer deep script block logging.
The latter records all PowerShell actions in the event log. These entries can be encrypted using Protected Event Logging and thus be protected from prying eyes. Overall, PowerShell has a number of mechanisms that make malicious use much more difficult.
Lee Holmes has compiled a table on Microsoft's PowerShell team blog that compares the security features of different programming languages and shells. The table shows that PowerShell offers more options than the others for preventing unwanted use. Of course, this does not provide the ultimate security, because resourceful minds always find ways to bypass the defense.
|Event Logging||Transcription||Dynamic Evaluation Logging||Encrypted Logging||App Whitelisting|
|CMD / BAT||No||No||No||No||Yes|
|Antimalware Integration||Local Sandboxing||Remote Sandboxing||Untrusted Input Tracking|
|CMD / BAT||No||No||No||No|
* Feature exists, but cannot be enforced via policies
Subscribe to 4sysops newsletter!
However, to benefit from these protections, admins must make a greater effort than simply blocking powershell.exe. As a benefit, they can keep PowerShell as a fully available system management tool that can even be fine-tuned to delegate tasks to standard users.