AMSI Assembly Scanning

We previously covered Anti-Malware Scanning Interface (AMSI) and the security benefits it provides. In summary, it allows for Anti-Virus scanning of script content, such as PowerShell.

Attackers had been using malicious PowerShell code for quite a while to conduct their operations, but as PowerShell logging improved and AMSI started detecting these scripts, the trend has been to move towards .NET Malware.

What is an assembly?

An assembly is the building block of a .NET application. Assembly’s can be compiled as a self-contained .exe file, or a DLL file.

So what attack are we talking about here?

 Let’s say you’re an attacker, and you want to run a malicious program on an endpoint. Let’s use Rubeus as an example. If you run the application from disk without modification it will likely be detected by Anti-Virus software.

To get around this, we can load the application directly into memory. This is pretty trivial to do with .NET code. We just need to;

• Serialise our copy of Rubeus. Serialisation is the process of translating a data structure into a format where it can be stored. So we essentially convert Rubeus.exe to a very long string of text.
• Load our serialised application into memory. This can be done in .NET by using the following method:

Assembly.Load(AssemblyBytes)

For attackers, this is great. We can load all our malicious code in memory without touching disk or being detected.

Microsoft did cotton onto the effectiveness of this technique, and with .NET Framework version 4.8 added the ability to scan code that Assembly.Load executes ☹

Back to the Drawing Board

 OK, so it was a good technique whilst it lasted. Is there a way we can still use it?

Understanding AMSI

AMSI works by injecting code into the address space of the monitored application. We can observe this behaviour by looking at libraries being loaded by the application;

Amsi.dll has been added into the address space of our application, and I certainly didn’t request it!

This already sets off a red flag, as since the application is under our control, we can modify the contents of its memory including amsi.dll.

If we can prevent amsi.dll from scanning our malicious code, then we can continue loading our code without detection 😊

Examining AMSI.DLL

 First, we need to determine how we can stop AMSI from scanning.

Checking Microsoft’s documentation we can see that the AmsiScanBuffer has the following description; “Scans a buffer-full of content for malware”. So that appears quite pivotal to the scanning process.

Next, we can examine the process using IDA Pro disassembler. The code has debugging symbols enabled, so we can go directly to the AmsiScanBuffer function.

Based on the graph, it looks we can determine if something happens the value 0x80070057 is placed into the EAX register. It turns out this is the code used to indicate scanning has failed. In that event, the system fails open allowing our malicious code to execute without detection.

So let’s see if we can make that happen with some C# code;

The below snippet of code locates the AmsiScanBuffer function in amsi.dll and sets it’s memory to writable so we can tamper with it;

var lib = LoadLibrary(“amsi.dll”);

_ = VirtualProtect(memloc, (UIntPtr)patch.Length, 0x40, out uint oldProtect);

Now we just need to overwrite the contents of the function so it always returns the value 0x80070057. This technique is pretty well known, so we will need to obscure our intentions slightly. We can do this with a bit of assembly code to put the value in EAX and return;

nasm > mov eax, 0x923B56CF

00000000  B8CF563B92        mov eax,0x923b56cf

nasm > sub eax, 0x12345678

00000000  2D78563412        sub eax,0x12345678

nasm > ret

00000000  C3                ret

Back in our C# code we can copy the assembly code into memory;

var p = new byte[] { 0xB8, 0xCF, 0x56, 0x3B, 0x92, 0x2D, 0x78, 0x56, 0x34, 0x12, 0xC3 };

Marshal.Copy(p, 0, memloc, p.Length);

The Result

 Monitoring the applications memory using WinDBG, we can see the effect our code has. Before tampering, amsi.dll is doing its thing;

After tampering we can see the application will always return 0x80070057 and therefore does not scan any malicious code.

Closing Thoughts

Userland security controls are prone to tampering. That’s not to say AMSI is completely ineffective. It’s still a useful security control, but due to it’s design it has limitations that you should be aware of. There are a number of methods to bypass AMSI, and Anti-Virus vendors frequently add new detections for these techniques. For now the game of cat and mouse continues…

How can IRM help protect your business?

Please contact sales@irmsecurity.com for more information.