The objective of this work package is the analysis of the Powershell and Windows Script Host (WSH) features in Windows 10 as well as the relevant communication interfaces, logging- and configuration capabilities.

• PowerShell and Windows Script Host Version: 1.0
• Tools Powershell Analysis

Due to the long duration of this project, a differential analysis between the original version Windows 10, Build 1607 and Windows 10 Enterprise LTSC 2019 (Build 1809) was carried out for this work package. This version will be supported by Microsoft until 2029.

No significant changes had been identified during this differential analysis.

• Download the differential analysis of Powershell

Table of contents analysis document

1 Introduction
1.1 Zusammenfassung (german)
1.2 Executive Summary
2 Concepts and Terms
2.1 Powershell: Architecture Overview
2.2 Windows Script Host: Architecture Overview
3 Technical Analysis of Functionalities
3.1 Powershell: Execution
3.1.1 Execution Locations
3.1.2 Execution Context
3.2 Deactivation
3.2.1 Powershell
3.2.2 Windows Script Host
4 Configuration and Logging Capabilities
4.1 Configuration Capabilities
4.1.1 Powershell
4.1.2 Windows Script Host
4.2 Logging Capabilities
Appendix
References
Keywords and Abbreviations

Summary:

Windows Sctipt Host (WSH) is a Windows technology that provides scripting abilities with a wide range of supported features. WSH is typically used for performing tasks that require automation, such as system administration tasks. WSH interprets and executes scripts written in different script languages, such as JScript and VBScript. WSH features a central script engine implemented in the executables %SystemRoot%\System32\cscript.exe and %SystemRoot%\System32\wscript.exe. cscript.exe executes scripts in console mode, whereas wscript.exe executes scripts in graphical mode. The WSH central script engine does not have the ability to interpret specific scripting languages, but imports language interpretation functionalities from external script engines. These script engines are implemented in Dynamic Link Library (DLL) files located in the %SystemRoot%\System32 directory. Examples are vbscript.dll, which is a VBScript script engine, and jscript.dll, which is a JScript script engine.

The PowerShell component of Windows 10 provides a well-defined environment for conducting system management activities. It enables users to conduct such activities in a straightforward manner using a well-defined language executing functionalities of the .NET framework, that is, of a set of .NET libraries (assemblies). The main functionalities of PowerShell (e.g., script interpretation and execution) are implemented as part of the System.Management.Automation .NET assembly. If this assembly is removed from a system, PowerShell is no longer functional. This may significantly hinder system management activities.

PowerShell is distributed with a number of security mechanisms, such as mechanisms that restrict PowerShell capabilities and the system resources which PowerShell may access for management purposes. In addition, PowerShell implements extensive logging mechanisms, which may be used for the identification of malicious PowerShell usage. These security and logging mechanisms are implemented as part of the .NET assemblies that implement the PowerShell system management functionalities.

Windows 10 is distributed with two versions of PowerShell – version 2.0 and version 5.1. By default, only PowerShell of version 5.1 is active and it cannot be deactivated in a straightforward manner. PowerShell of version 2.0 can be activated as a Windows Feature through a user interface. This effectively makes the underlying .NET assemblies, specific for PowerShell of version 2.0, available to users. These .NET assemblies do not implement all security and logging mechanisms implemented by the .NET assemblies specific for PowerShell of version 5.1. Therefore, the use of PowerShell of version 2.0 is not recommended.

Since PowerShell is a powerful system management mechanism, malicious use of PowerShell can have a severe impact on system security. The well-defined language provided by PowerShell is attractive to attackers, since it enables them to conduct complex malicious activities in a straightforward manner. It is important to emphasize that PowerShell is a subject to the standard Windows role-based access control mechanism restricting access to system resources to authorized users.

Due to PowerShell’s attractiveness to attackers, the use of PowerShell should be based on a concrete concept specifying the deployment and use of the security and logging mechanisms of PowerShell. This concept should be specifically tailored to the system management requirements for the Windows 10 instance on which PowerShell is active. Such a concept is important to avoid or mitigate potential malicious use of PowerShell.