How malicious PowerShell scripts evade detection

Over the last few years, PowerShell has increasingly become a favorite tool among those who have malicious intent. After all, PowerShell is installed natively as a part of Windows, it has the ability to interact with most of the operating system’s components, and it also has remote access capabilities.

Another reason why the bad actors often use PowerShell as an attack vector is because it can be difficult to detect a PowerShell-based attack. PowerShell is a part of the Windows operating system, and malicious activity can easily blend in with legitimate administrative activity.

Malicious PowerShell scripts getting smart to sandboxes

That being the case, when an IT pro downloads a PowerShell script, they will often test the script inside of a sandboxed environment prior to running it in production. That way, they can check to see if the script attempts any harmful behavior. However, those who create malicious scripts are increasingly designing scripts that are able to differentiate between a sandbox environment and a production environment. This allows the script’s author to trick IT pros into running the script in their production environment because the script appears to be harmless when executed in a sandbox.

This, of course, raises the question of how malicious script authors can tell whether or not a script is running in a sandbox environment. There are actually several different techniques that are sometimes used, so I want to show you a few.

VirtualBox

VirtualBox is one of the more commonly used tools for testing PowerShell scripts. However, it is relatively easy for a PowerShell script to figure out if it is running inside of a VirtualBox environment because VirtualBox installs components into the Windows operating system to help it to function within the VirtualBox environment. These components function similarly to the VMware Tools or to the Hyper-V Integration Services. Therefore, if a script author wants to check to see if their script is running in a VirtualBox environment, then all they have to do is to check for the presence of the various VirtualBox components.

One such component is the VirtualBox Guest Additions Service, or VBoxService.exe. While a script author could conceivably construct a script that checks for the existence of the VBoxService.exe file, it is just as easy to use the Get-Process cmdlet to see if the vboxservice process is installed. Here is how such a script might work:

$A = (Get-Process | Select-String -Pattern vboxservice).count
If ($A -GT 0) { $Virtual = $True} Else {$Virtual = $False}

This block of code counts the instances of the VBoxService process that are running on the machine and then assigns that count to a variable named $A. If the count is greater than zero, then it means that the process does exist, and the PowerShell session is presumably running inside of VirtualBox. The script creates a variable named $Virtual that is set to $True if the code detects the presence of the VBoxService process and $False if the process is not detected. You can see an example of this in the screenshot below.
Malicious PowerShell

Hyper-V

VirtualBox is not the only environment that is used to test PowerShell scripts. Hyper-V is also a commonly used testing environment. Just as it is possible to construct a PowerShell script to detect whether it is running inside of a VirtualBox machine, it is also possible to test whether a PowerShell session is running inside of a Hyper-V virtual machine.

The easiest way that I know of to find out if PowerShell is running inside of a Hyper-V virtual machine is to use the Get-WmiObject cmdlet to retrieve system information from Win32_ComputerSystem. As you can see in the screenshot below, PowerShell will actually tell you if it is running on a virtual machine when you run this command:

Get-WmiObject -q “Select * from Win32_ComputerSystem”

Malicious PowerShell
In case you are wondering, the screenshot below shows what happens if you run this command on a physical machine.

In this case, the model is displayed as System Product Name because I am working from a computer that I built myself. If this were a vendor-supplied system, then the model would be displayed as Dell, HP, or something similar.

Here is how you can use this code to tell whether or not PowerShell is running inside of a Hyper-V virtual machine:

$A = Get-WmiObject -Q “Select Model From Win32_ComputerSystem”
If ($A.Model -eq “Virtual Machine”) {$Virtual = $True} Else {$Virtual = $False}

The two images below show what happens when you run this code on a virtual machine.


Malicious PowerShell

Does the script have admin permissions?

One more thing that malicious script authors sometimes do is to include a test to determine whether a script is running in an elevated PowerShell session. That way, they can design the script to avoid attempting anything malicious until the proper permissions are detected. There are countless ways of testing to see if administrative permissions exist. This method was adapted from serverfault.com.

Here is the code:

$user = [Security.Principal.WindowsIdentity]::GetCurrent();
If ((New-Object Security.Principal.WindowsPrincipal $user).IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator) -eq $True) {$IsAdmin = $True} Else {$IsAdmin = $False}

This code creates a variable called $IsAdmin This variable is set to $True if the user is a member of the built-in administrator group and $False if the user is not. Keep in mind that this code only looks at the user’s permissions, not whether the PowerShell session has been elevated. Here are a couple of examples:

Malicious PowerShell
In the images above and below, the user is not an admin.

Malicious PowerShell

Malicious PowerShell scripts hiding in plain sight

Malware authors are increasingly creating malicious PowerShell scripts that are designed to hide their true intentions. These scripts will generally behave benignly if they are found to be running inside of a virtual machine or if they lack administrative privileges but will perform malicious activity when the conditions are right. The techniques shown in this article, while not all-inclusive, illustrate some of the ways that malicious script authors test the environment within which their script is running.

Featured image: Shutterstock

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top