PowerShell has become the ultimate administration tool. However, the scripting language is also enjoying increasing popularity among attackers by allowing them to penetrate systems without detection and work their way up the network (Figure 1). Fortunately, administrators are not completely defenseless, because PowerShell 5 offers some useful security features that both limit the use of the scripting language and block other attack paths.

Figure 1: PowerShell allows all kinds of high jinks that can also be misused for attacks.

Windows PowerShell is a powerful tool that combines the command line with a script interpreter. The execution of instructions always linked to the user's context sufficiently arouses the attention of IT security admins; other special features can be viewed critically. Many admins equate PowerShell with the PowerShell.exe file; by simply blocking the executable file, they hope PowerShell will no longer be accessible. However, this is not correct. The following code fragment shows the true nature of PowerShell as part of Microsoft's .NET framework:

$ObjWPS = [POWERSHELL]::Create();
$ObjWPS.AddCommand("get-service");
$ObjWPS.Invoke();

PowerShell is stored in the shared library System.Management.Automation.dll, which means that PowerShell code execution is not limited to PowerShell.exe alone. However, in conjunction with AppLocker and new security elements in PowerShell 5, a secure environment is possible.

Restrict Admin Rights

Just Enough Administration (JEA) is a new feature of Windows Management Framework 5. The idea behind this security technology is to limit the administrator's rights to what is absolutely necessary to perform a task. JEA uses a role-based approach to set up and automate restrictions on IT staff and reduces the risks associated with deploying full administrator rights.

JEA can also be implemented with PowerShell, because everything you can manage with PowerShell can be more securely managed with JEA. JEA provides standardized methods to reduce administrative access with a finer granular rights system than traditional access control models. JEA is based on PowerShell limited runspaces, a technology designed by Microsoft to secure management tasks in environments such as Exchange Online and Azure.

JEA provides a Role-Based Access Control (RBAC) platform that can create a management endpoint on any computer and use it locally or remotely as the base for PowerShell. JEA is implemented as a PowerShell session endpoint that contains a PowerShell session configuration file and one or more role capability files. For an overview of possible session endpoints, use the Get-PsSessionConfiguration command.

PowerShell session configuration files define who is allowed to connect to an endpoint. Users and security groups can be assigned administrative roles. Global settings affect virtual accounts and transcription policies, whereas the session configuration files are machine-specific.

The role capability file restricts the actions and access for users of a specific role. Possible restrictions could affect specific cmdlets, functions, providers, or external programs. The graphical JEA Helper Tool from Microsoft [1] helps create the endpoint configurations.

Language Restrictions with $ExecutionContext

To make things more difficult for attackers, the execution of object methods can be disabled, putting PowerShell in a restricted command mode. The language scope is controlled with the environment variable $ExecutionContext.SessionState.LanguageMode. Because the variable is not write protected, you can assign it one of the following value:

• FullLanguage – No restrictions.
• RestrictedLanguage – No property reference, no method calls, no object initialization, and no change of host settings are possible.
• NoLanguage – No language elements are available for use.
• ConstrainedLanguage – Static methods of a class are not executed; only core types are referenced.

Log Actions

You can use Group Policy to enable a system-wide transcript for tracking PowerShell actions (Figure 2). Logging provides information about the PowerShell host, start time, and on which system PowerShell.exe or PowerShell_ISE.exe was running. The text files created here are automatically named to avoid a collision with existing logs. Unfortunately, Windows does not allow access to a file from multiple processes at the same time.

Figure 2: Enable logging of PowerShell actions in Group Policy.

The path should also be chosen carefully, because the default is the user directory, which makes it easier to attack the logfiles themselves. Best practices dictate choosing a centralized network share, which also facilitates evaluation. You can extend the scope of the logs to individual modules; after configuration, it is independent of the -Path parameter specified in the start-Transcript command. In this case, system-wide logging runs in parallel with optional logging created by the user. The corresponding settings can be found in Group Policy under Administrative Templates | Windows Components | Windows PowerShell .

The PowerShell Logging setting is interesting for security considerations, because it logs all PowerShell actions, including script calls. If access to a certain module is relevant, specific logging for the use of a command container can be activated. Because modules encapsulate cmdlets to manage servers and services such as Active Directory or Hyper-V, traceability in the event of IT infrastructure disruptions is also important.

The Turn on PowerShell Script Block Logging menu item is somewhat misleading. It actually logs the code that PowerShell executes. Otherwise, the instructions are transcribed sequentially, making it far more difficult to create useful indicators.