What is an AMSI bypass?

You may have heard about an AMSI bypass in the context of a work conversation, but what exactly is it and how does it work? Read on to learn more about it.

What is AMSI?

Before we dive into what an AMSI bypass is, it pays off to first understand what AMSI is. AMSI is short for Antimalware Scan Interface and it's Microsoft's safeguard against malicious content running on a computer. It integrates into the existing antimalware/endpoint defense product that is on the system and it's vendor agnostic. Particularly, it can scan script content and pass it to the security software on the system prior to the script content being executed on the host. The goal of AMSI is to prevent the execution of arbitrary code containing malicious content.

For example, if I were to try to run the PowerShell version of Mimikatz on a host without performing any sort of bypass, it would look something like this:

In this specific scenario, I loaded and tried to execute Invoke-Mimikatz.ps1 in a non-privileged, non-special shell. What AMSI did was scan the contents of the script after it was teed up to execute (but prior to actual execution), pass it to Windows Defender for a signature check, and Windows Defender passed it back with the malicious content result.

AMSI Bypassing

There are ways to circumvent AMSI in order to successfully execute malicious code, and some are listed below:

Forcing an AMSI Initialization Failure

If AMSI can't even initialize, then it won't be able to scan script-based content. One can force initialization failure by passing the following code into a PowerShell session:

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

Note that in order for this to work, it's highly recommended that the code be obfuscated. Microsoft has developed signatures against the above string and it will likely not work if run as is. The original failure bypass technique was developed by Matt Graeber.

Variants of this method have been developed by other researchers as well, and a simple Google search will yield obfuscated and sophisticated versions for your use.

Downgrading PowerShell

AMSI protection is only supported in PowerShell versions beyond v2.0. This means that if the attacker can downgrade the PowerShell version in the session to that of 2.0, they can circumvent AMSI and execute the intended code. This is demonstrated in the screenshot below:

You can see that when I run the $PSVersionTable command, I had already set my PowerShell version to version 2. I ran the Invoke-Mimikatz.ps1 script with no problems. However, when I reverted the PowerShell version to version 5, AMSI did what AMSI does.

For this circumvention to work, note that there have to be some other ideal conditions in place. For one, the execution policy has to be set to "bypass" to allow for the execution of unsigned scripts. Additionally, .NET Framework 3.5 (including .NET 2.0 and 3.0) needs to be installed and available on the system. Without this framework version being available and installed, PowerShell version 2 will not be able to run.

Scan with AMSITrigger

AMSITrigger is a program developed by RythmStick with the objective of detecting all of strings in a script that would be considered malicious by AMSI. It does this by making calls to AMSI using AmsiScanBuffer() and highlighting when the returned result is AMSI_RESULT_DETECTED.

The image below, from RythmStick's Github showing AMSITrigger working with Invoke-Mimikatz:

The output highlights the strings detected by AMSI, therefore making it easy for the user to go into the scanned script and make changes to the strings. Oftentimes actions such as removing the synopsis at the top of the script, reversing values, and changing variable names is enough for the script to then pass the AMSITrigger test once re-checked.

Nishang

Nishang is a tool developed by Nikhil Mittal: renown speaker, instructor, and contributor. Nikhil incorporated an AMSI bypass module into Nishang, "Invoke-AMSIBypass," which leverages publicly known bypass methods in order to circumvent the security implementation.

To use, it's as simple as copying the code from his Github and pasting it into an active PowerShell session. Once that's complete, simply run "Invoke-AmsiBypass" with the verbose parameter if you'd like to see which method is being used, and execute:

Conclusion

So, in a nutshell:

AMSI = Windows trying to stop you from doing offensive security script-based things

AMSI Bypass = Telling Windows to kick rocks and figuring out how to run your offensive security script-based things anyway :)

I hope this blog post was insightful and helpful, and I appreciate those of you who took the time to read it!