It’s a never ending cat-and-mouse game: bad guys develop malware and good guys try to detect and mitigate malware to protect the end user. Whenever manufacturers of antivirus software come up with a new method of detecting malicious code or files, hackers find a way to circumvent that technique.
One particularly elegant technique of transmitting and executing malware has gained popularity in the last couple of years with both hackers and pentesters alike: Microsoft’s built-in tool PowerShell. It provided a convenient way of executing code directly in-memory without ever touching the disk. Since many antivirus products relied on scanning executables which are written on the disk, this attack vector was completely invisible to them.
Rapid7’s exploit framework Metasploit made it extremely simple to apply this technique. A module called Web Delivery gives the user a short one-liner (or rather two-liner, but it’s still manageable), a so-called download cradle, that executes whatever payload you want on the target. However, much to the dismay of many a pentesters, the Windows Defender, Kaspersky’s endpoint protection, and possibly other antivirus software started to monitor and detect “suspicious” PowerShell activity. In particular, it was game over for the popular Web Delivery.
This is largely due to a function called Antimalware Scan Interface (AMSI), which passes code to a malware detection engine before execution, no matter the execution method – disk or memory: it doesn’t matter. The cat quickly reacted and found a method to disable AMSI. It’s a short piece of code which does not require any special privileges and fits in a tweet:
ERROR: Content Element with uid "3041" and type "parsedown_markdown" has no rendering definition!
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:
ERROR: Content Element with uid "3043" and type "parsedown_markdown" has no rendering definition!
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.
Imagine you are an antivirus product. How would you decide whether something is malware or not? You could do several things.
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.
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.
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.
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.
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.
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):
ERROR: Content Element with uid "3045" and type "parsedown_markdown" has no rendering definition!
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 (stage1):
ERROR: Content Element with uid "3047" and type "parsedown_markdown" has no rendering definition!
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:
ERROR: Content Element with uid "3049" and type "parsedown_markdown" has no rendering definition!
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.
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:
ERROR: Content Element with uid "3051" and type "parsedown_markdown" has no rendering definition!
It contains:
Of course, the encryption key is right next to the encrypted payload. But antivirus products are not smart enough (yet) to recognize this. That’s precisely what AMSI was made for. It would pass the decrypted script block to the antivirus product before letting Invoke-Expression execute it.
Finally, our efforts yield a Meterpreter session on an up-to-date Windows 10 system with a running instance of Kaspersky Total Security (see Figure 1).
Windows Defender was also successfully bypassed. More antivirus products are currently being tested by us.
Ihr direkter Kontakt zu SySS +49 (0)7071 - 40 78 56-0 oder anfrage@syss.de | IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN +49 (0)7071 - 40 78 56-99
Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer
Ihr direkter Kontakt zu SySS +49 (0)7071 - 40 78 56-0 oder anfrage@syss.de
IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN +49 (0)7071 - 40 78 56-99
Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer
Direkter Kontakt
+49 (0)7071 - 40 78 56-0 oder anfrage@syss.de
IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN
+49 (0)7071 - 40 78 56-99
Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer