Defend Against Powershell Attacks

To give system managers a number of advantages over traditional interfaces for streamlining and automating administrative chores, Microsoft created PowerShell, a built-in scripting language and command-line executor. The strength of PowerShell renders it a handy instrument for attackers to conduct file-less exploits, which are challenging to block and identify. Essentially, the PowerShell script is a simple text file with an a.ps1 extension. When you execute the file on the prompt, it will begin to run. Which scripts are executed can be managed by the PowerShell user. There are various steps one may take to minimize malicious files because this might be risky when the user has nefarious intent.

We’ll talk about potential defenses against PowerShell assaults in this article which can be easily employed to strengthen the PowerShell system. This article will cover the following:

PowerShell scripts security

Keeping lateral movement at bay

PowerShell attack detection and prevention

Using the following methods, PowerShell attacks can be prevented:

Powershell Scripts Security:

• PowerShell execution policy configuration: Microsoft limits the implementation of PowerShell scripts to stop users from inadvertently running scripts that they should not have been. Additionally, these limitations aid in preventing the use of dangerous scripts in social engineering initiatives.

Why to harden PowerShell and not remove it completely

Use the Set-ExecutionPolicy cmdlet and one of the following parameters to set the execution policy:

1. The most constrained choice is Restricted. The loading of configuration files and the execution of scripts are prohibited by selecting this option. In the PowerShell console, you will nevertheless be able to execute lone commands.
2. If you select the AllSigned option, all scripts and configuration files will need to be digitally signed by a reputable publisher. A certificate for code-signing is used while signing.
3. When a script or configuration file is downloaded from the Internet, it must be digitally signed, according to the option Remote-Signed. On your computer’s local network, however, you can load scripts and configuration files that are not signed.
4. All scripts can run, and all configuration files can be loaded if you select the Unrestricted option. Considering that it is the least limiting option, it is also the one that runs the most risk.

• 509 Certificate Creation: The next thing to be done is that you must singe the file once the execution policy has been changed to AllSigned. A code-signing X.509 certificate must be made in order to accomplish that. The X.509 cryptography standard is one that you can either make yourself or buy from a public certificate authority.

• PowerShell script authentication: Use the certificate you’ve created to sign your scripts after you’ve created it. The script file to sign must be specified along with your certificate when using the Set-AuthenticodeSignature cmdlet. You will be given the option to decide if it is acceptable to execute a digitally signed script before running it. You have the option of running the file once, at this time, constantly, or never.

• Turn off PowerShell scripts using AppLocker: The usage of AppLocker to whitelist programs and scripts is advantageous. To establish a permitted rule that only applies to a particular folder, utilizes the Script Rules policies. This will make sure that just the files in this folder are executed.

• ‘Constrained Mode’ configuration for PowerShell: PowerShell Constrained language limits to access to sensitive language components that can call arbitrary Windows APIs while supporting PowerShell’s daily operations. Utilizing application control technologies in conjunction with PowerShell Constrained mode is an efficient technique to reduce network hazards.

Keeping lateral movement at bay

It’s not just PowerShell assaults that employ lateral movement. But you may take a number of steps to reduce the likelihood that attackers will deploy PowerShell-based lateral movement techniques:

• Disable WinRM when it is not necessary to do so in order to avoid PSSession. This command enables an interactive remote PowerShell session that a user can use to run commands from a distance. The Windows Remote Management (WinRM) service is required for this option. To utilize this technique, the WinRM must be activated. Where possible, set the ‘Allow remote server management with WinRM’ option to Disable. If this setup is not an option, set up the WinRM in the most secure way you can.
• Set the policy setting “Allow Remote Shell Access” to “Disable” to control the configuration of remote script and command execution for all supported shells. You can reduce the possibility of malicious use by attackers by turning it off.
• Disable Windows Server Message Block (SMB) - A lot of the techniques that use PowerShell to migrate laterally use Windows Server Message Block (SMB). Attackers who use PsExec-type programs won’t be able to do so if SMB is disabled.
• Set a minimum liberties policy; if the attacker gets write access to the PowerShell profile files on a remote computer, he is able to add malicious software to them.

PowerShell attack detection and prevention

PowerShell is well-known for its robust activity-logging features that can be used to identify and counteract tool misuse. Administrators can utilize the following three activity-logging features to examine PowerShell activities and establish the scope of an invasion:

• Module logging: By turning on module logging, PowerShell would keep track of the execution of each module, such as the deobfuscate codes and outputs. For logging applications, it is advised to enter a value of “*” to record everything.
• Logging for script blocks: If you enable this option, logs will be produced each time a script block is used. Although it might be a valuable tool for attack detection, it comes with additional security dangers.
• PowerShell Transcription: When PowerShell Transcription is enabled, all input and output out of a PowerShell transaction are captured.

Attackers can utilize PowerShell as a vital tool at different points and in different ways during an assault. But by establishing secure settings for network services and elements, many of these choices can be disabled. Check to see if your system has been sufficiently toughened before looking for methods to boost your PowerShell security. This can be done by employing the methods mentioned above. These methods are tried and tested systems that will prevent attackers from making your system weak or misusing any information you have on PowerShell.

Automated Hardening Tools:

PowerShell is a powerful tool for attackers to use, but many of these options can be blocked by setting secure configuration services and components in your system.

Before searching for but tools that can increase your PowerShell security, make sure your system is properly hardened. We recommend using automation for this task since it is a rather complicated and mistake-prone mission. Learn how CalCom automates hardening  .