PowerShell Execution Checks - OS Test

PowerShell's execution policy is a safety feature that controls the conditions under which PowerShell loads configuration files and runs scripts. This feature helps prevent the execution of malicious scripts.

The PowerShell execution policies are as follows:

• AllSigned: This policy requires that all scripts and configuration files be signed by a trusted publisher, including scripts that you write on the local computer. The policy prompts you before running scripts from publishers that you have not yet classified as trusted or untrusted.

• Bypass: This policy blocks no script; neither does it give prompts or warnings during script execution. This execution policy is designed for configurations in which a PowerShell script is built in to a larger application or for configurations in which PowerShell is the foundation for a program that has its own security model.

• RemoteSigned: This requires a digital signature from a trusted publisher on scripts and configuration files that are downloaded from the internet which includes email and instant messaging programs. The policy does not require digital signatures on scripts that are written on the local computer and not downloaded from the internet.

• Restricted: This policy permits individual commands, but does not allow scripts. It prevents running of all script files, including formatting and configuration files (.ps1xml), module script files (.psm1), and PowerShell profiles (.ps1).

• Unrestricted: The policy allows unsigned scripts to run. It warns the user before running scripts and configuration files that are not from the local intranet zone.

These execution policies are however not 'set in stone'. In other words, administrators can override the execution policy set at the system level by configuring a different execution policy at the current user or individual frame session level. They can also easily bypass a policy by typing the script contents at the command line when they cannot run a script.

This is why, even if a secure execution policy (e.g., AllSigned, RemoteSigned etc.) is set at the system/server level, there is always the danger of unsecured PowerShell scripts - e.g., unsigned scripts, scripts executed with the Unrestricted or Bypass execution policy etc. - being executed on a Omnissa Horizon desktop. If malicious scripts are allowed to run, they can open the gates of hell! These scripts can allow hackers back-door access to your sensitive data, so they can misuse it! 

To avoid this, it is important for administrators to know what execution policy is set for the target system, keep an eye out for PowerShell scripts that override that policy, and scrutinize those scripts to see if they pose any potential security threats. This is exactly what the PowerShell Execution Checks test helps administrators achieve!

This test monitors the PowerShell scripts that are run on the target virtual desktops and reports the count of scripts that are run with 'risky' execution policies. The test also reveals the PowerShell execution policy that is set for the target virtual desktop, thus enabling administrators to rapidly determine if there are scripts that override this execution policy. Detailed diagnostics of the test provide the name and location of these scripts, so administrators can pull them up for a closer look and determine whether/not they are 'safe'.

Note:

This test pulls metrics from the Windows PowerShell logs. For this test to work therefore, you should turn on module logging, script Execution and PowerShell script block logging for Windows PowerShell on the Windows system being monitored. To achieve this, follow the steps below:

1. Login to the target Windows host.

2. With the Windows icon on the key board pressed, press the R key, to open the Run prompt. At the prompt, type gpmc.msc, see Figure 1

   

   Figure 1 : Typing gpmc.msc in the Run text box

3. This will open the Group Policy Management Console.

4. Then open the Group Policy Management Editor and edit or create a new GPO. For that, right-click Group Policy Objects in the domain where the GPO is to be created and select New. This will invoke Figure 2, in the New GPO dialog box in Figure 2, specify a name for the new GPO, and then click OK . (or) Open the Group Policy Objects node. Right-click the appropriate GPO, and click Edit.

   

   Figure 2 : Creating new GPO

    

5. To configure policies, expand the Computer Configuration node in the left panel of Figure 3 and select its Policies sub-node and then navigate to Administrative Templates ->Windows Components . Select Windows Powershell setting from the right panel of Figure 3.

   

   Figure 3 : Selecting Windows Powershell setting from Windows Components

6. This will invoke Figure 4 .Right-click Turn on Module Logging in the Windows Power Shell Setting, then select Edit.

7. In the window that appears, click the Enabled radio button. Click on the Apply and OK buttons. Next, click on the Show button in the Optionsand Show contents section will appear. Double-click on the first cell under the Value column to make it editable. Then, specify Microsoft.Powershell.* therein, so that logging is enabled for all PowerShell modules. Then, click the OK button in Show contentssection to save the changes.

   

   Figure 4 : Selecting and enabling the Turn on Module Logging option

8. Similarly, Turn on PowerShell Script Block Logging in the Windows Power Shell Setting. See Figure 5

   

   Figure 5 : Selecting and enabling Turn on Powershell Script Block Logging option

9. Now to enable Turn on Script Execution setting, right-click Turn on Script Execution in the Windows Power Shell Setting, then select Edit. This will invoke Figure 6. Then, select Allow local scripts and remote signed scripts from the Execution policy drop-down in Figure 6. Then, click the OK button.

   

   Figure 6 : Selecting and enabling Turn on Script Execution

10. This will take you back to Windows Power Shell Setting, where you can see that the Turn on Module Logging, Turn on Script Execution, and Turn on PowerShell Script Block Loggingsettings now displays Enabled as the State.

11. Apply the GPO to the appropriate organizational unit (OU) or computer.

Target of the test : Amazon Cloud Desktop Group

Agent deploying the test : A remote agent

Outputs of the test : One set of results for the monitored Amazon Cloud Desktop

Configurable parameters for the test

Parameter	Description
Test Period	How often should the test be executed.
Host	The host for which the test is to be configured.
Port	The default port is NULL.
Inside View Using	To obtain the 'inside view' of performance of the cloud-hosted virtual desktops - i.e., to measure the internal performance of the virtual desktops - this test uses a light-weight eG VM Agent software deployed on each of the desktops. Accordingly, this parameter is by default set to eG VM Agent.
Report By User	This flag is set to Yes by default. The value of this flag cannot be changed. This implies that the virtual machines in VDI environments will always be identified using the login name of the user. In other words, in VDI environments, this test will, by default, report measures for every username_on_virtualmachinename.
Report Powered OS	This flag is relevant only for those tests that are mapped to the Inside View of Desktops layer. If this flag is set to Yes (which is the default setting), then the 'inside view' tests will report measures for even those virtual desktops that do not have any users logged in currently. Such desktops will be identified by their name and not by the username_on_virtualdesktopname. On the other hand, if this flag is set to No, then this test will not report measures for those virtual desktops to which no users are logged in currently.
Is Cloud VMs	Since this test runs for every virtual desktops component which is a cloud-hosted desktop group, this flag is set to Yes by default.
Ignored Path	Provide a comma-separated list of paths that needs to be excluded from monitoring in the Ignored paths text box. Wild card characters can be used to indicate file paths- for eg., to ignore all file paths that contains the word 'agent', your specification can be: *agent*. By default, this parameter is set to *egurkha* indicating that all file paths that contains egurkha are excluded from monitoring. You can change this default setting if you need.
Detailed Diagnosis	To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measurements made by the test

Measurement	Description	Measurement Unit	Interpretation
Unsigned executed scripts count	Indicates the number of unsigned PowerShell scripts that are currently executing on the target virtual desktop.	Number	Ideally, the value of this measure should be low. A high value of this measure means that many unsigned scripts are being executed on the monitored virtual desktop. This increases the probability of malicious scripts being executed, which can be detrimental to the safety and overall health of your system. In such a case therefore, use the detailed diagnosis of this measure to know which unsigned scripts were executed, how frequently, and from which folder. With the help of this information, administrators can quickly identify the potentially 'unsafe' scripts, and review those scripts to see if they can be allowed to run going forward.
Scripts executed with unrestricted execution policy	Indicates the number of scripts that are running with the Unrestricted execution policy.	Number	The Unrestricted execution policy allows unsigned scripts to be run, which in turn can be a potential security risk to your critical virtual desktop servers/systems. This is why, a low value is desired for this measure. If this measure reports a high value, you are advised to use the detailed diagnosis of this measure to identify the scripts that are running with this policy, and where they are located. You may want to scrutinize the scripts to look for security holes.
Scripts executed with remote signed execution policy	Indicates the number of scripts that are running currently with the RemoteSigned execution policy.	Number	The RemoteSigned policy allows scripts downloaded from the internet to run only if they are signed by a trusted publisher. Though this policy is more secure, it allows unsigned scripts to run, if they are written on the local computer. Likewise, unblocked scripts are allowed to run under this policy, even if they are unsigned and downloaded from the internet. So, this policy does introduce an element of 'risk' to your mission-critical systems/servers. Therefore, if the value of this measure reports a non-zero value, its best to use the detailed diagnosis of the measure to know which scripts are using the RemoteSigned policy, and where these scripts are stored. Using this information, you can quickly pull up these scripts for a closer look, so you can confirm that they are safe to run.
Scripts executed with bypass execution policy	Indicates the number of scripts that are running currently with the Bypass execution policy.	Number	Bypass is one of the 'less-safe' execution policies as it allows script execution without putting up a fight - i.e., without any blocks, warnings, or prompts. Ideally therefore, the value of this measure should be low. If a high value is reported, then use the detailed diagnosis of the measure to know which scripts are running with the Bypass policy, how frequently, and where are the scripts located. These details will help you look into such scripts and corroborate their safety and authenticity.
System PowerShell execution policy	Indicates the PowerShell execution policy that is currently set at the virtual desktop server/system-level.	Number	The values that this measure reports and the execution policies they represent are tabulated below: Measure Value Execution Policy 1 AllSigned 2 Undefined 3 Default 4 Restricted 5 RemoteSigned 6 Bypass 7 Unrestricted You may want to compare the value of this measure with that of the measures to know if the system's policy was overridden during script execution.