Msfvenom
Introduction
Like multi/handler, msfvenom is technically part of the Metasploit Framework, however, it is shipped as a standalone tool. Msfvenom is used to generate payloads on the fly.
it can also be used to generate payloads in various formats (e.g. .exe, .aspx, .war, .py)
Syntax
The standard syntax for msfvenom is as follows: msfvenom -p <PAYLOAD> <OPTIONS>
For example, to generate a Windows x64 Reverse Shell in an exe format, we could use:
Encoders
Shikata Ga Nai (SGN)
The phrase SGN in the Japanese language means “nothing can be done”. SGN is a polymorphic XOR additive feedback encoder. It is polymorphic in that each creation of encoded shellcode is going to be different from the next. It accomplishes this through a variety of techniques such as dynamic instruction substitution, dynamic block ordering, randomly interchanging registers, randomizing instruction ordering, inserting junk code, using a random key, and randomization of instruction spacing between other instructions. The XOR additive feedback piece in this case refers to the fact the algorithm is XORing future instructions via a random key and then adding that instruction to the key to be used again to encode the next instruction. Decoding the shellcode is a process of following the steps in reverse. Its name to use is x86/shikata_ga_nai
Staged vs Stageless
Staged Reverse Shell Payloads
Staged payloads are sent in two parts -- The first part is called the stager. This is a piece of code which is executed directly on the server itself. It connects back to a waiting listener, but doesn't actually contain any reverse shell code by itself. Instead it connects to the listener and uses the connection to load the real payload, executing it directly and preventing it from touching the disk where it could be caught by traditional anti-virus solutions. Staged payloads require a special listener -- usually the Metasploit multi/handler
Staged payloads are harder to use, but the initial stager is a lot shorter, and is sometimes missed by less-effective antivirus software. Modern day antivirus solutions will also make use of the Anti-Malware Scan Interface (AMSI) to detect the payload as it is loaded into memory by the stager, making staged payloads less effective than they would once have been in this area.
Stageless Reverse Shell Payloads
Stageless payloads are more common. They are entirely self-contained in that there is one piece of code which, when executed, sends a shell back immediately to the waiting listener.
Stageless payloads tend to be easier to use and catch; however, they are also bulkier, and are easier for an antivirus or intrusion detection program to discover and remove.
Payload Naming Conventions
When working with msfvenom, it's important to understand how the naming system works. The basic convention is as follows: <OS>/<arch>/<payload>
For example:
linux/x86/shell_reverse_tcpThis would generate a stageless reverse shell for an x86 Linux target.
The exception to this convention is Windows 32bit targets. For these, the arch is not specified. e.g.:
windows/shell_reverse_tcp
For a 64bit Windows target, the arch would be specified as normal (x64).
In the above examples the payload used was shell_reverse_tcp. This indicates that it was a stageless payload. Stageless payloads are denoted with underscores (_).
The staged equivalent to this payload would be: shell/reverse_tcp, As staged payloads are denoted with another forward slash (/).
This rule also applies to Meterpreter payloads. A Windows 64bit staged Meterpreter payload would look like this: windows/x64/meterpreter/reverse_tcp
A Linux 32bit stageless Meterpreter payload would look like this: linux/x86/meterpreter_reverse_tcp
List Payloads
To list all available payloads, msfvenom --list payloads
Which can then be piped into grep to search for a specific set of payloads.
Last updated