Staged vs Non-Staged Payloads
In this section,
we’ll explore the differences between staged and non-staged payloads.
Let’s assume we’ve identified a buffer overflow vulnerability in a service.
As we learned in Fixing Exploits,
we need to be aware of the buffer size our shellcode will be stored in.
If the shellcode size of our exploit exceeds the buffer size,
our exploit attempt will fail.
In a situation like this,
it’s vital which payload type we choose:
staged or non-staged.
The difference between these payload types is subtle but important.
A non-staged payload is sent in its entirety along with the exploit.
This means the payload contains the exploit
and full shellcode for a selected task.
In general, these “all-in-one” payloads are more stable.
The downside is that the size of these payloads will be bigger than other types.
In contrast, a staged payload is usually sent in two parts.
The first part contains a small primary payload
that causes the victim machine to connect back to the attacker,
transfer a larger secondary payload containing the rest of the shellcode,
and then execute it.
Now that we have a basic understanding of these two types of payloads,
let’s practice them.
For this, we’ll use the same exploit module as in the previous section
and enter show payloads
to get a list of all payloads that are compatible
with the currently selected exploit module.
The output shows us the payload we used before at index 20.
In Metasploit, the forward slash character
is used to denote whether a payload is staged or not,
so shell_reverse_tcp at index 20 is not staged,
whereas shell/reverse_tcp at index 15 is.
Let’s use the staged payload for this exploit module and launch it.
We should note that Metasploit will reuse
the values for the options from the previous payload.
The output shows that we successfully obtained a reverse shell
by using the staged payload.
The output states that the sent stage was only 38 bytes in size,
making it a great choice when we attempt to exploit a vulnerability
with space constraints.