PowerShell as a hacking tool: Prevent abuse of scripts

PowerShell is a powerful tool for system administration; as such, it is also the perfect entry point for hackers. Due to PowerShell's tight integration into the system, attempts to simply block it provide a false sense of security. The best protection is provided by PowerShell's own mechanisms.

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 ^

Quite a number of tools can be easily obtained as open source via Github. These include the extensive script and module collections PowerSploit, PowerShell Empire, Nishang, and PowerUp.

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.

Windows Defender prevents downloading PowerSploit

Windows Defender prevents downloading PowerSploit

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.

Blocking powershell.exe with software restriction policies

Blocking powershell.exe with software restriction policies

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.

PowerShell 2.0 is an optional feature starting with Windows 8 and Server 2012 and is enabled by default

PowerShell 2.0 is an optional feature starting with Windows 8 and Server 2012 and is enabled by default

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.

When running PowerShell on remote machines, Session Configurations and Just Enough Administration can effectively reduce the threat potential.

Selecting the allowed parameters of a cmdlet for JEA

Selecting the allowed parameters of a cmdlet for JEA

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.

The event viewer presents only the encrypted entries; it cannot decode them

The event viewer presents only the encrypted entries; it cannot decode them

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 LoggingTranscriptionDynamic Evaluation LoggingEncrypted LoggingApp Whitelisting
BashNo**No*NoNoYes
CMD / BATNoNoNoNoYes
JScriptNoNoNoNoYes
LUANoNoNoNoNo
PerlNoNoNoNoNo
PHPNoNoNoNoNo
PowerShellYesYesYesYesYes
PythonNoNoNoNoNo
RubyNoNoNoNoNo
shNoNoNoNoNo
T-SQLYesYesYesNoNo
VBScriptNoNoNoNoYes
zshNoNoNoNoNo

 

 Antimalware IntegrationLocal SandboxingRemote SandboxingUntrusted Input Tracking
BashNoNoYesNo
CMD / BATNoNoNoNo
JScriptYesNoNoNo
LUANoNoYesYes
PerlNoNoYesYes
PHPNoNoYesYes
PowerShellYesYesYesNo
PythonNoNoNoNo
RubyNoNoNoYes
shNoNoYesNo
T-SQLNoNoNoNo
VBScriptYesNoNoNo
zshNoNoYesNo

* Feature exists, but cannot be enforced via policies
**Experimental

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.

Join the 4sysops PowerShell group!

Your question was not answered? Ask in the forum!

2+
avatar
Share
0 Comments

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2020

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account