Bypass AMSI in 2025

Although AMSI has been analysed and described in many papers and tools, I'm still surprised to see so much confusion and misunderstanding in the community. For example, a lot of shellcode loaders were published on GitHub that do nothing more than shellcode execution. But the README also states that it contains an AMSI bypass, and that's why it's never detected. So there is a lot of misunderstanding, at least on GitHub or social networks, which may confuse more and more people out there.

When do we really need to use an AMSI bypass? At least for shellcode execution - we don't. AMSI, as I wrote in my blog more than four years ago, is primarily used to analyse scripting languages and .NET managed code at runtime, such as

• Powershell
• VBS
• Javascript
• VBA macros
• C# assemblies

So if you are using a Command & Control Framework's payload and are mainly running BOF's or COFF's from there, you will never need to bypass AMSI at all. If you do implement a bypass in your loader, you will only increase the IoCs and the likelihood of being detected by that bypass attempt. It's always better to leave out bypasses unless you really need them!

On the other hand, if you want to run known malicious and unobfuscated public tools, e.G. from GitHub in any of the above languages, or reuse code from them in your own tools, you will need to bypass AMSI to get those tools to run. Are you going to execute GitHub Scripts via Invoke-Expression in Powershell? Are you loading a .NET assembly via assembly::load()? Creating malicious office macros? Loading Scripts into memory via mshta.exe, cscript.exe? or wscript.exe? You will likely need an AMSI bypass.

AMSI is mostly signature-based detection. The main difference to classic signature-based detections is that these signatures are looked for at runtime, whenever something potentially malicious is loaded from memory. AMSI by architecture also doesn't trigger a scan at all at certain points when something is loaded from disk into memory, as recently pointed out by IBM X-Force Red.

What might AMSI signatures look like? They can be simple strings like Invoke-Mimikatz, but also byte arrays like the bytes used for the classic AmsiScanBuffer patch:

For C# assemblies, this can be specific HEX bytes, but in my experience AMSI also uses some kind of Yara rules - or at least regular expressions. But if AMSI is about signatures, this also means that we can always get around it by modifying the code. If you change the code so that the signature doesn't apply, you can bypass AMSI. As "simple" as that, although signatures are sometimes difficult to find out.

The alternative to bypassing AMSI detection is to somehow break functionality within amsi.dll or other libraries involved in the scanning process, or to prevent the DLL from loading at all. This is what almost all publicly documented bypasses are about. They differ mainly in the technique used to break the functionality, such as

• Patching the memory region (also includes hooks from my perspective)
• Using vectored exception handlers and e.g. hardware breakpoints to manipulate the workflow
• Spawning a new process and preventing one of the relevant DLLs from loading in various ways
• Prevent one of the relevant DLLs from being loaded before the CLR is started and/or AMSI is initialised

These things are usually done at runtime. IoCs, and therefore detection of these bypasses, rely on:

• Signatures for the bypass code, or
• Runtime detections such as userland hooks, ETWti or memory scans.

At first glance it looks like we did, but only for the Powershell script itself and not for the Rubeus assembly that gets called at runtime. Why is that? This has already been described in my 2nd private blog. So in this case we would have to obfuscate the assembly first, embed it and then obfuscate the Powershell script. And we would need to go through this approach for each and every assembly/script. Might it be easier to just use an existing AMSI bypass instead?

The first bypass is a special case by now. When it was published, it worked for both Powershell scripts and loaded .NET assemblies. But after publication Microsoft adjusted something from within Powershell, so that it doesn't affect scripts anymore at all but instead just .NET assemblies. So this can be combined with one of the orange marked bypasses or if your script is not flagged and it loads assemblies - that's fine.

For all the green ones, you only need to obfuscate/modify the source for signature evasion and you're good to go. The red ones are much more likely to get flagged these days due to patch-based detections. Orange ones will only help for native Powershell scripts, but the moment assembly::load is called, AMSI is not bypassed at all. In some cases you may also need to remove Add-Type and stick to native Powershell alternatives. Very few vendors also use clr.dll hooks, in these cases you may also fail due to behaviour-based detections and need to unhook clr.dll.

The Provider Patch has two code snippets in my repo, the one with Add-Type only works for Powershell scripts, the one using reflection works for both scripts and .NET assemblies.

As you can see, the green/orange ones still contain some patch based bypasses. But these are less known/used and therefore not checked/found by memory scans in my experience.

In a few cases, EDR vendors don't even rely on amsi.dll for their scan anymore. Any bypass that targets this specific DLL will not result in a bypass at all. In these cases you will need to enumerate their AMSI provider DLL via the registry or memory walking and patch that or alternatively the custom AMSI DLL. More information can be found in this blackhat talk from 2022.

The C# assembly specific AMSI bypass from IBM linked above already should also not get flagged at all on runtime by now. This whole concept of "tricking" the CLR into loading an assembly from disk was not new and already published with another .NET specific bypass in 2021. Since that release, Windows Defender's behaviour has not changed, and loading assemblies via the PoC SharpTransactedLoad still works. However, some EDR vendors don't behave the same and also apply AMSI scans to assemblies loaded from disk, so at least the 2021 PoC is no longer fully OpSec safe.

After reading a blog post trying to get around about the recent Defender patch detections, I got curious to dig into these detections myself. What else could cause such a detection? The most known public patches use 0xC3 (RET) somewhere at the entry point of AmsiScanBuffer to exit the function and return INVALID ARG, making the caller think that nothing malicious was found. Let's play around here, just for fun.

Is it just the entry point?

As I said earlier, I believe that Defender uses a memory scan to check for malicious actions before it takes action. So is the memory scan just checking the beginning of the function? What does that entry point look like?

Fun fact: You may remember that Defender used to flag the strings amsiscanbuffer, amsi.dll and the patch bytes as malicious, right? This is no longer the case, as this newly introduced detection is now the primary one to find and prevent a patched AmsiScanBuffer function. So these "old" signatures have now been replaced by the memory scan.

The two shown bypasses - and memory signatures for it's patches - are in theory easy to add after publication of this blog, so don't expect them to hold for too long. But the good news is that there are dozens of other patch alternatives. You just have to be creative in adjusting the patch offset and bytes.

Much of the content that was relevant years ago to bypass AMSI is still relevant several years later. It's still a lot about signatures and getting around signatures by doing manual modification or obfuscation. Years old obfuscation tools are still not covered by generic signatures for some reason. But some EDR vendors did build AMSI based signatures for it, which effectively makes the tool without modifications useless. Modification or obfuscation in general however is still enough to completely evade AMSI detection, but with many different vendors and therefore different signature databases, it's hard to be sure that they're all bypassed.

Alternatively, manipulation of DLLs involved in the AMSI process at runtime leads to a generic bypass, so that known malicious scripts or assemblies can be loaded. Published bypasses mainly use memory patches or vectored exception handlers with e.g. hardware breakpoints to manipulate the scan or initialisation process at runtime. Some others rely on manipulating the DLL load process - either when AMSI hasn't been initialised yet or for newly spawned processes.

What's effective in 2025? From my perspective, effectiveness can be measured in terms of behaviour-based detections, as all bypasses can be easily modified to avoid signature-based detections. In my experience, using patches on the entry point of amsi.dll functions is no longer considered secure, as several vendors have been detecting these patches for a few years now via memory scans triggered by kernel events. Using hardware breakpoints can be considered more OpSec safe at the time of writing, but vendors are starting to use behaviour-based detections for this as well, and the cat and mouse game continues. Manipulating the DLL load process or the AMSI initialisation before it is loaded is not yet detected by behaviour, but can only be used before initialisation or for newly spawned processes.

Although patching at the entry point is no longer considered safe due to memory scan detections, patching at custom offsets is still appropriate for amsi.dll. Alternatives that patch clr.dll or other DLLs involved in the AMSI process usually don't trigger a memory scan based detection either. So is patching dead? I would say that it is far from dead.