What is PowerShell Hardening?

• December 20, 2022June 8, 2023

PowerShell Hardening

What is PowerShell?

PowerShell is an embedded scripting language and a command-line executor developed by Microsoft to provide a better interface for system administrators to simplify and automate administrative tasks. It is an important part of the system administration toolkit due to its ubiquity in Microsoft Windows systems and the ease with which it is used to fully control Windows systems. The main use of PowerShell is to enable task automation, data accessibility, manage infrastructure as code, and facilitate remote commands. The power of PowerShell makes it a useful tool for attackers for fileless attacks that are difficult to block and detect.

PowerShell is integrated with the .NET Framework and has full access to Component Object Model (COM) and Windows Management Instrumentation (VMI) functionality. It also has full access to the Windows Application Programming Interface (WinAPI) via the .NET Framework. This provides a powerful and easy-to-use interface to the underlying system and also allows automation of various tasks.

However, it should be noted that PowerShell can be run locally or over a network through a feature known as Windows Remote Management (WinRM). To achieve this, remote communication must be enabled on the remote workstations and servers where the code is executed. In Microsoft Windows Server 2012 and newer Microsoft operating systems, remote access is enabled by default.

Security Issues of PowerShell:

PowerShell is generally used when the attacker gains code execution during initial access. It allows attackers to perform code injection from the PowerShell environment into other processes without releasing malicious code to disk, effectively enabling arbitrary code execution while bypassing many security protections and leaving virtually no residue on a system.

This is not due to any vulnerability within PowerShell, but rather is indicative of its tight integration with the .NET Framework, which provides an extremely powerful and easy-to-use interface to sensitive system functions. PowerShell allows the attacker to have an attacker-friendly interface to enumerate and manipulate the host system after gaining initial code execution authority. At the same time, PowerShell can directly run malware without having code execution authority. The possible effect of the malware running will be remote code execution with the help of C2 after the malware runs.

Not releasing malicious code to disk can be difficult to determine when a cyberattack has occurred and can make forensic investigations significantly more difficult to conduct. Combined with the extensive functionality that PowerShell provides, it is clear that PowerShell is an extremely powerful post-exploitation tool.

Despite the security improvements provided by Microsoft, there are three main reasons why attackers prefer PowerShell;

1. Powerful scripting environment,
2. Direct access to Win32 API with large install base
3. It is mostly not well protected.

PowerShell is a powerful tool for attackers to use in various forms and stages in an attack. However, exploitation of PowerShell can be prevented by making secure configuration settings for the services and components in the systems.

For example, Kovter, a fileless click fraud malware, hides its malicious modules entirely in the registry. These modules are then injected into the PowerShell process, prompting the click fraud process to start when the infected system reboots.

Fileless Malware Phishing PowerShell:

1. The phishing e-mail sent by Kovter lands in the spam box.
2. Automatically installs components for Shell Spawning techniques.
3. It creates registry entries containing malicious scripts.
4. Injects a script into the PowerShell process upon system reboot or after batch file execution.
5. The shell code will launch the regsvr32.exe process, which will connect to various URLs for click fraud.

Given the threat of fileless attacks, it is important to enable PowerShell logging and store data for later analysis. There are two types of logging in PowerShell.

• PowerShell Module Logging
• PowerShell Script Block Logging

PowerShell Module Logging: Module Logging records pipeline execution details as PowerShell is executed, including variable initialization and command calls. Module logging records parts of scripts, some obfuscated code, and some formatted data for output. While this logging will not reliably capture commands executed, it will capture some details missed by other PowerShell logging sources. Module Logging has been available since PowerShell 3.0. Module logging is written to Event ID (EID) 4103.

To Enable Module Logging;

1. After entering the Local Group Policy Editor, clicking on Administrative Templates in Device Configuration, double-clicking on Windows PowerShell in Windows Components, clicking on the Turn on Module Logging section, selecting enable and confirming. Click on the show option next to the Module Names section and enter the value specified in the box. “*” We write the value.

1. Open the Registry Editor HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\PowerShell\ModuleLogging go to the directory and click Activate Module directory Edit with Dword and select the value "one" we do.

1. Open the Registry Editor HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\PowerShell\ModuleLogging\ModuleNames After going to the directory and clicking Edit String, click Data Value in the section indicated in the picture. “ * “ We enter the value.

Script Block Logging: Script Block Logging records blocks of code as they are executed by the PowerShell engine, thus capturing the entire content of the code executed by an attacker, including scripts and commands. By its very nature, Script Block logging also records obfuscated code while it is being executed. For example, in addition to saving the original encoded code, PowerShell can use decoded commands passed with the -EncodedCommand argument, as well as XOR,Base64,ROT13, encryption, etc. It also saves commands hidden with . Script Block Logging does not record output from executed code. Script Block Log logging events are recorded at EID 4104.

To Enable Script Block Logging;

1. Script Block Logging appears after entering the Local Group Policy Editor, clicking Administrative Templates in Device Configuration, then double-clicking Windows PowerShell in Windows Components. Enabled After clicking, we select enable and confirm.

1. Open the Registry Editor HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\PowerShell\ ScriptBlockLogging Go to the directory and click on the Activate Module directory Edit with Dword and select the value "one" we do.

Each of these sources records unique data that is valuable for analyzing PowerShell activity. In environments where log sizes cannot be increased significantly, enabling script block logging and transcription will log most activity while minimizing the amount of log data generated. At least script block logging must be enabled to identify attacker commands and code execution.

Suggestions:

In most cases, standard users do not need PowerShell when performing their daily tasks. Only network administrators and IT professionals who need PowerShell for legitimate work tasks should have access. Giving PowerShell access to standard users creates unnecessary risk for companies. Since PowerShell has administrative functions, it may sometimes not be possible to prevent its execution. Instead, it may be necessary to disable or at least restrict access to the Windows Remote Management Service to restrict access to authorized network administrators and IT professionals, as well as to prevent the use of PowerShell for remote execution.

For enterprise-level Windows PowerShell security, it is necessary to know the basics before installing this security. Users should use the latest version of Windows PowerShell. The user should mention here that PowerShell security should be set with the latest version of Windows PowerShell. A lower version (such as PowerShell version 2) may do more harm than good. Therefore, users are advised to always use the latest versions of PowerShell and keep it constantly updated. At the same time, users should be given the latest version of Windows PowerShell as well as the latest version in the operating system. Windows 11 or Windows 10 is the most compatible operating system to install PowerShell security. Therefore, users are advised to upgrade their older Windows versions to Windows11/10 and review all the security features available to them.

Why should you implement PowerShell secure scripts?

PowerShell secure scripts are a feature we don't need as much until we do. In small organizations where the management of the IT infrastructure is delegated to a small number of employees, running signature scripts is a normal scenario. Because the infrastructure environment is smaller and there is much more transparent communication within the team. Especially when it comes to knowing who does what.

Controlling who works on what and on which systems is complex in an enterprise environment where management of such infrastructure will be delegated across teams, sometimes across different geographic locations. Getting the right people to run the right scripts can be even more difficult.

All of this leads to potential problems such as execution control, command hijacking, identity and integrity.

In PowerShell, execution control specifies which scripts the system runs. Accordingly, Windows has four types of execution control policies; Restricted, AllSigned, RemoteSigned and Unrestricted.

Restricted: It is the most restrictive policy where the system does not allow the execution of any local, remote or downloaded scripts.

AllSigned: It forces all scripts to be digitally signed using a certificate, otherwise the system will not run them.

RemoteSigned: It allows remote UNC(Universal Naming Convention) and downloaded scripts to run only if they are digitally signed. Native scripts can be run regardless.

Unrestricted: It's unrestricted in most companies, especially smaller ones where there's a single system administrator who doesn't need a scripting application. In this case, all scripts will run regardless of whether they are digitally signed or not.