The different stages of a PowerShell attack

PowerShell is a scripting language and a command-line executor developed by Microsoft to provide a better interface for system administrators to simplify and automate administrative tasks. Although it was developed for administrative usage, it can also be used to support an attacker's goal during a breach.

How to prevent powershell attacks

The following post will present the different stages of a PowerShell attack:

1. Bypassing the execution policy
2. Script execution
3. Lateral movement
4. Persistence

1. Bypassing execution policy:

Microsoft restricts PowerShell scripts with an execution policy to prevent users from accidentally executing scripts they shouldn't execute. These restrictions also help prevent people from running malicious scripts in social- engineering campaigns.

The default execution policy setting is Restricted (except for Windows Server 2012 R2, where it is Remote- Signed). This default policy allows users to run only interactive PowerShell sessions and single commands, regardless of the origin of the scripts or whether they are signed and trusted.

Organizations set different policies to address their needs. However, attackers use different methods to bypass the execution policy. These are the most common bypasses:

• Echo the script and pipe it into the standard-in of PowerShell– in order to execute this bypass, pipe the script into the PowerShell standard input with echo or type command. This technique won't change configurations or require writing to disk.

• Echo the script and pipe it into an interactive PowerShell console- this is the most basic bypass, and will be useful for running scripts in an interactive console. In order to execute this bypass, you'll need to copy and paste the PowerShell script into an interactive console. This technique won't change configurations or require writing to disk. However, using this technique you'll be limited to your user's privileges.

• Download the script from a URL and use invoke expression to execute it- in the technique, you can download a PowerShell script from the internet and execute it without writing on the disk and changing configurations.

• Read a script from a file and pipe it to standard-in- use Windows 'type' command, or PowerShell 'get-content' command to read a script from the disk and pipe it to the PowerShell standard input. This bypass will need to write the script on the disk, but there'll be no configuration changes. To avoid writing on the disk, you can read the script from a network share.

• Use the 'Command' switch- this bypass is similar to interactive console bypass, but doesn't require the use of an interactive console. The disadvantage of this bypass is that complex scripts usually result in parsing errors. This bypass won't result in configuration changes or writing to disk.

• Use the 'EncodeCommand' switch- this technique is very similar to the 'use the 'Command' switch' bypass, only, in this case, the scripts are provided as Unicode or base64 encoded strings. This helps to avoid parsing errors that usually happen when you use the 'Command' switch. There'll be no configuration changes or writing to disk when using this bypass.

• Use the 'Invoke-Command' command- this bypass can be used the execute commands against remote systems, where PowerShell remoting is enabled. It is usually executed through an interactive console or one-liner with the 'Command' switch. This bypass won't result in configuration changes or disk writing.

• Use the 'Invoke-Expression' command- this bypass is usually executed using an interactive console and does not result in configuration changes or disk writing.

• Use 'Bypass' execution policy flag- when this flag is used nothing is blocked and there'll be no warnings or prompts. It is used when the attacker is executing scripts from a file. It won't result in configuration changes in writing to disk.

• Use 'Unrestricted' execution policy flag- when this flag is used it loads all configuration files and runs all scripts. The attacker will be prompted for permissions when running unsigned scripts that were downloaded from the internet. This bypass won't result in configuration changes of writing to disk.

• Use the 'Remote-Signed' execution policy flag- this is the default policy for Windows servers. This flag doesn't require a digital signature on scripts that are written on the local computer. When it is used, it runs scripts that are downloaded from the internet and not signed only if the scripts are unblocked.

• Disable execution policy by disabling the 'AuthorizationManager'- the following function can be executed through an interactive console or the 'command' switch: function Disable-ExecutionPolicy {($ctx = $executioncontext.gettype().getfield(“_context”,”nonpublic,instance”).getvalue( $executioncontext)).gettype().getfield(“_authorizationManager”,”nonpublic,instance”).setvalue($ctx, (new-objectManagement.Automation.AuthorizationManager “Microsoft.PowerShell”))} Disable-ExecutionPolicy  .runme.ps1

This function will swap out the 'AuthorizationManager' with null. This will lead the execution policy to be set as unrestricted for the current session. This bypass won't result in configuration changes of writing to disk.

• Set the ExecutionPolicy to Scope Process- the execution policy can be set to unrestricted for the rest of the session for the process which you have control over. This bypass won't result in configuration changes of writing to disk.

• Set the ExecutionPolicy to Scope CurrentUser using the Command switch- This bypass is similar to the previous one, but will apply the setting to the current user's environment by modifying the registry key. This bypass won't result in configuration changes of writing to disk.

• Set the ExecutionPolicy to Scope CurrentUser using the registry- this bypass is similar to the previous one, only it modifies the registry key directly.

2. Script Execution:

PowerShell used are usually used as downloaders of additional payloads after the exploitation phase. The execution policy will prevent users from running scripts with .ps1 extension, but attackers can use other extensions to execute their scripts. PowerShell uses command-line flags that can be used maliciously to evade detection and bypass local restrictions.

The most frequently used malicious PowerShell commands and functions in the command line are:

• (New-Object System.Net.Webclient).DownloadString()
• (New-Object System.Net.Webclient).DownloadFile()
• -IEX / -Invoke-Expression
• Start-Process

System.Net Webclient class is used to send or receive data from remote resources. This class includes the DownloadFile method, which downloads content from a remote location to a local file. It also includes the DownloadString method which downloads content from a remote location to a buffer in the memory.

After the payload is downloaded, another method is used to run the additional code. The most commonly used methods to start a new process from PowerShell are Invoke-Expression and Start-Process.

Here are some of the most common infection methods:

• Flags- Attackers uses this environment variable to hide the script from command-line loggers.
• Emails- very commonly used as a delivery vector for PowerShell downloaders. The attackers use social engineering to trick the user into opening the attachment and enabling its content. If the user opens the attached files, the PowerShell script launches.
• Nemucod downloader- a Trojan that downloads malicious files to an infected computer
• Office macros- use of malicious macros in Office documents. Attackers use emails to trick the user into enabling and executing the macro in the attachment, and the macro drops a PowerShell script.

3. Lateral movement:

Lateral movement techniques allow attackers to spread across the environment from a single compromised computer. Attackers use remote PowerShell commands to spread laterally. Lateral movement depends on the computer's configuration and the user's permissions. Here are some of the most commonly used PowerShell lateral movement methods.

• Invoke-command- the Invoke-Command allows PowerShell scripts to be run on remote computers. The attacker can both supply and execute the command on multiple remote computers in parallel.

• Enter-PSSession- the PSSession command allows interactive remote PowerShell session, which the user can use to execute commands remotely. This option depends on the Windows Remote Management (WinRM) service. The WinRM must be enabled in order to use this method.

• WMI- WMI can be used to run the application on remote computers. It is not limited to PowerShell scripts, but it is easy to leverage it for this purpose.

• Profile injection- if the attacker has a ‘write’ privileges to PowerShell profile files on a remote computer, he can add malicious code to them.

• Using system or public tools- such as Task Scheduler, PsExec, and Mimikatz.

4. Persistence:

Creating persistent load points that restart the backdoor is a commonly used method for attackers to maintain their presence in the network. Those load points are activated each time that Windows restarts. Here are a few common methods that use PowerShell in order to maintain persistence in the network:

• Registry- attackers store a script in the registry, making the infection completely fileless and their attack hard to detect. Having access to the registry will also allow the attacker to set the execution policy. This is probably the most common load point.

• Scheduled tasks- the attacker can create a task that will be triggered in a specific moment and will execute a PowerShell command.

• Startup folder- a Startup folder enables a user to automatically run a specified set of programs when Windows starts. A small script file can be placed in a Startup folder that will be executed after Windows restarts.

• WMI- WMI is powerful when used in combination with PowerShell. The attacker can create a filter for a specific event that will be supported by a consumer method to execute the malicious script. It can be used both locally and remotely.

• Group policies (GPOs)- by modifying existing policies, attackers can use GPOs to add a load point for a backdoor PowerShell script.

• Infect local profiles- an attacker can place malicious code in either one of the six PowerShell profiles, or create its own profile. The code will be executed when PowerShell starts.