Back in the old days, there were separate instances of the Metasploit Framework that you could fire up from the command line for generating payloads; they were msfpayload and msfencode. Kids these days can generate payloads with the one-stop shop Metasploit Framework instance called msfvenom. Aside from the obvious advantage of a single command line with standardized flags for fine-tuning your attack, msfvenom is also faster.

So, what are payloads? It's best if we first understand the core structure of Metasploit: modules. Modules are objects within Metasploit that get a certain job done, and the nature of the task defines the type of module. Payloads are just a module type within Metasploit, and their job is to contain code for remote execution. Payloads are used by exploit modules, which are effectively delivery systems for our payload; however, we will discuss that in more detail later. For now, we're looking at payload generation that can stand alone. This will give you unmatched flexibility when you're in the field.

There are three different kinds of payload such as singles, stagers, and stages. Singles are the true standalones of the bunch. They don't even need to talk to Metasploit to phone home—you can catch them with a simple netcat command. Stagers and stages are obviously related but distinct. A stager sets the stage for getting data to and from a target; that is, a stager creates a network connection. A stager payload is going to execute and then try to phone home, and thus get around pesky Network Address Translation (NAT) firewalls by being initiated from the inside. Stages are the payload components conveyed to the target by the stager. Using the very common meterpreter connect-back example, the meterpreter component itself is the stage, and the module that creates the TCP connection back to the attacker is the stager. Of course, there's no point in phoning home if no one is answering, so we rely on handlers to receive and handle any connections.

Let's now check out what msfvenom offers us when we fire it up in a terminal window. Please note that for illustrative purposes, we will define the full names of the options. You are welcome to use the shorter flags in practice (for example, --payload is the same as -p):

# msfvenom -h

Let's explore some of the following command lines:

• The --payload command defines the payload we're going to use. Think of this as a behavior; this is what our payload is going to do. We'll take a good look at specific payloads next.
• The --list command will output the available modules for a given module type. So, let's say you're stuck on --payload, you can issue msfvenom --list payloads to get the list. However, if you don't already know exactly what to build, you may need this list. If you'd rather utilize the search function in msfconsole, don't worry, we'll look at that next.
• The --nopsled command is a shellcoding option that we will explore in more detail in Chapter 10, Windows Shellcoding.
• The --format command represents the file type that'll be created. This is where you'd specify EXE for when you're making dastardly executables. This particular option, however, is an area where the flexibility of msfvenom really shines, as there are many formats available. We'll be looking at a few in this book, but commanding --help-formats will help you get acquainted. 
• The --encoder command is another option that we'll dive into in greater detail in Chapter 10, Windows Shellcoding. An encoder can change how code looks without changing the underlying functionality. For example, perhaps your payload needs to be encoded in an alphanumeric representation, or you need to eliminate characters that break execution. You would combine this with --bad-chars to get rid of code-breaking characters such as 0x00. How a payload is encoded can be repeated over and over again with --iterations, which defines the number of passes through the encoder. This can make the payload a little more stealthy (that is, harder to detect), but it's worth pointing out that encoding isn't really meant to bypass anything—its real purpose is getting the code ready for a particular environment. 
• --arch and --platform allow you to specify the environment where a payload is going to run, for example, 32-bit (instruction set architecture) Windows (platform).
• The --space command defines the maximum size of your payload in bytes. This is handy for situations where you know there is some sort of restriction. Encoded payload space is the same, unless you want to define it as a different value; in which case, you'd use --encoder-space. Also useful is --smallest, which generates the smallest possible payload.
• --add-code allows us to create a two-for-one deal by injecting the shellcode from a different generated payload into this payload. The source can be an executable or it can even be the raw output from a previous run of msfvenom. You can do this a few times over, potentially embedding several payloads into one, though in reality you'll likely run into encoding problems if you do this.
• The --template command allows you to use an existing executable as a template. A Windows executable is made up of many pieces, so you can't just spit out some shellcode on its own—it needs to go somewhere. A template has everything needed to make a working executable—it's just waiting for you to put your shellcode in it. You could also identify a specific executable here if you wish, and msfvenom will dump your payload into the text section of the executable (where general purpose code put together by a compiler is located). This is powerful on its own, but this option is made all the more covert when used in tandem with --keep, which keeps the original functionality of the template EXE and puts your shellcode in its own new thread at execution.
• The --out command defines the path where our payload gets spat out. 
• The --var-name command will matter to us when we cover shellcoding, but even then, it doesn't actually do much. It's really for the guy who likes to stand apart from the crowd and use custom output variable names.
• The --timeout command is a newer feature for the generation of large payloads; it prevents timeout while the payload is being read. The need for this came about from users who were piping the output of msfvenom into msfvenom. You probably won't use this option but it's nice to know it's there.