PowerShell: An Attacker’s Paradise

PowerShell was originally intended as a task automation and configuration management program for system administrators. However, it didn’t take long for attackers to realize its potential for carrying out offensive operations without being detected.

Due to PowerShell’s versatility, it can be seen in all stages of attacks, from initial infection vectors; used in macros of infected documents to being used in post-exploitation to dump credentials, using the infamous mimikatz PowerShell module.

We’ll look at a few scenarios where and how PowerShell is used with malicious intent and the challenges faced in detecting these attacks. This blog will showcase where a heavily obfuscated PowerShell command is used to execute shellcode and how attackers can bypass AMSI to avoid detection.

Why attackers use PowerShell

• PowerShell is signed by Microsoft and is virtually present on every Windows system. Its omnipresence on Windows operating systems makes it an ideal choice for attackers to evade detection and eliminate the need to bring more tools into their attack arsenal.
• PowerShell allows passing the input as encoded commands without the need to drop any files on the disk. This results in achieving obfuscation and makes attacks stealthier.
• PowerShell can be used in all stages of the attack. Its usage ranges from malicious macros of MS Office documents for initial infection attacks to being used for dumping credentials in post-exploitation using mimikatz.
• Various bitwise operators and string operations available in PowerShell can be used to achieve a high level of obfuscation. Ex: ‘bxor, bor, join, replace’ can be used to mangle strings and commands to avoid detection from security products.
• More advanced use-cases like reflective dll-injection and shellcode execution can be performed quite easily. This is usually accomplished by utilizing a countless number of open-source projects which are readily available on the web.

Different Types of PowerShell attacks

Use in malicious macros

PowerShell is often used as an initial infection attack vector in malicious document macros. The complexity of these attacks ranges from simply downloading and executing second-stage payloads to more advanced use-cases to perform process hollowing.

Figure 1

In the example above, the function in the macro downloads additional payload/shellcode, which is then executed to gain access to the victim system.

Disabling AMSI to evade detection

Some PowerShell attacks have been spotted to first disable the AMSI protection provided by Microsoft. All PowerShell scripts/commands are subjected to an AMSI scan to prevent malware execution.

Figure 2

The above malicious code disables the AMSI interface by patching the ‘AmsiScanBuffer’ function in ‘amsi.dll’ by first changing the permissions on the memory, then writing the desired bytes.

Using Mimikatz in post-exploitation

Mimikatz is one the most commonly used post-exploitation tools used by hackers and malware authors. It is typically used to steal credentials and escalate privileges.

Mimikatz originally demonstrated ways and means to exploit a single vulnerability in the Windows authentication system in its initial avatar. However, it has now evolved quite a bit, and its latest version contains a myriad of other techniques.

Figure 3

The example above shows one of the ways in which mimikatz is executed. The script is directly downloaded from the GitHub repository and executed on the victim machine.

Encoded and compressed commands

One of the most powerful features of PowerShell is the use of encoded commands as input without ever dropping a file to the disk. Besides encoding, it even allows the use of compression (Gzip, in most cases), which further aids in the obfuscation of commands.

Figure 4

In Figure 4, we can see the input to the PowerShell is a large block of base64 command, which is run using the ‘EncodedCommand’ switch. The base64 command, when decoded, results in another set of encoded and gzip compressed commands listed as output.

Figure 5

Performing decoding and decompression on the output of the previous operations reveals the final set of commands that are used to run a shellcode using various Windows APIs, as illustrated in Figure 5 above.

Challenges in detecting PowerShell attacks

• Many legitimate applications also use PowerShell for various tasks; hence blocking PowerShell entirely is not the optimal solution, as doing so would prevent admins and users from optimizing and automating their legitimate tasks.
• It’s challenging to differentiate between benign and malicious PowerShell use. System admins use it to automate specific tasks like user creation and several maintenance tasks. A malicious actor could perform the same in post-exploitation attempts. Such similarity in genuine and malicious activities makes it difficult to identify and act upon the harmful PowerShell attacks.
• Most attacks are performed directly in memory using commands without ever touching the disk. This makes collecting artifacts related to the attack difficult as no files are written on the disk – which could have been used for forensic analysis.
• String-based signatures are challenging to write as many functions/operations are available in PowerShell, which can be used for obfuscation, bypassing security products.
• Most attacks use some encoding schemes to maintain stealth and avoid detection. To detect these effectively, multiple encoding schemes need to be supported.
• PowerShell provides a large attack surface. It can utilize other programs like WMIC to get information like the system’s patch level, which aids in launching further attacks. It can also make use of WScript and CScript to launch second-stage payloads.

How Quick Heal protects its users

Quick Heal and Seqrite protect their users from multiple stages of malware and attacks that abuse PowerShell. In addition to behavioral protection mechanisms, Quick Heal prevents malicious PowerShell execution through other modules, which include URL filtering, Anti Malware protection, Cloud, and Anti Ransomware protection.

Figure 6

Conclusion

Defending against PowerShell attacks is complicated. Due to its availability and ease of use, it provides cybercriminals and adversarial groups with a large attack surface.

There is no silver bullet for detecting and preventing PowerShell attacks. However, the protection provided by various detection technologies can help us mitigate its risks.

As users, we can protect ourselves from these threats by not running any untrusted PowerShell scripts while enabling the latest security features and keeping the QH antivirus and OS updated.

Mrigank Tyagi