Metasploit Understanding Payloads in Metasploit cardingcvvru, carderplanetsu
Advanced Ethical Hacking Institute in Pune
A payload in metapsloit refers to an exploit module. There are three different types of payload modules in the Metasploit Framework: Singles, Stagers, and Stages. These different types allow for a great deal of versatility and can be useful across numerous types of scenarios. Whether or not a payload is staged, is represented by ‘/’ in the payload name. For example,“windows/shell_bind_tcp” is a single payload with no stage, whereas “windows/shell/bind_tcp” consists of a stager (bind_tcp) and a stage (shell).
Singles are payloads that are self-contained and completely standalone. A Single payload can be something as simple as adding a user to the target system or running calc.exe.
Stagers setup a network connection between the attacker and victim and are designed to be small and reliable. It is difficult to always do both of these well so the result is multiple similar stagers. Metasploit will use the best one when it can and fall back to a less-preferred one when necessary.
Windows NX vs NO-NX Stagers
Stages are payload components that are downloaded by Stagers modules. The various payload stages provide advanced features with no size limits such as Meterpreter, VNC Injection, and the iPhone ‘ipwn’ Shell.
Payload stages automatically use ‘middle stagers’
We briefly covered the three main payload types: singles, stagers and stages. Metasploit contains many different types of payloads, each serving a unique role within the framework. Let’s take a brief look at the various types of payloads available and get an idea of when each type should be used.
Now that we have an understanding of what a payload is, payload types, and when to use them, lets generate some payloads.
During exploit development, you will most certainly need to generate shellcode to use in your exploit. In Metasploit, payloads can be generated from within the msfconsole . When you ‘use‘ a certain payload, Metasploit adds the ‘generate‘, ‘pry‘ and ‘reload‘ commands. Generate will be the primary focus of this section in learning how to use Metasploit.
Of course the odds of generating shellcode like this without any sort of ‘tweeking’ are rather low. More often than not, bad characters and specific types of encoders will be used depending on the targeted machine.
The sample code above contains an almost universal bad character, the null byte (\x00). Granted some exploits allow us to use it but not many. Let’s generate the same shellcode only this time we will instruct Metasploit to remove this unwanted byte.
To accomplish this, we issue the ‘generate‘ command followed by the ‘-b‘ switch with accompanying bytes we wish to be disallowed during the generation process.
Looking at this shellcode it’s easy to see, compared to the previously generated bind shell, the null bytes have been successfully removed. Thus giving us a null byte free payload.
We also see other significant differences as well, due to the change we enforced during generation.
One difference is the shellcode’s total byte size. In our previous iteration the size was 341 bytes, this new shellcode is 27 bytes larger.
During generation, the null bytes’ original intent, or usefulness in the code, needed to be replaced (or encoded) in order to insure, once in memory, our bind shell remains functional.
Another significant change is the added use of an encoder. By default Metasploit will select the best encoder to accomplish the task at hand. The encoder is responsible for removing unwanted characters (amongst other things) entered when using the ‘-b’ switch. We’ll discuss encoders in greater detail later on.
When specifying bad characters the framework will use the best encoder for the job. The ‘x86/shikata_ga_nai’ encoder was used when only the null byte was restricted during the code’s generation. If we add a few more bad characters a different encoder may be used to accomplish the same task. Lets add several more bytes to the list and see what happens.
We see a different encoder was used in order to successfully remove our unwanted bytes. Shikata_ga_nai was probably incapable of encoding our payload using our restricted byte list. Fnstenv_mov on the other hand was able to accomplish this.
Having the ability to generate shellcode without the use of certain characters is one of the great features offered by this framework. That doesn’t mean it’s limitless.
If too many restricted bytes are given no encoder may be up for the task. At which point Metasploit will display the following message.
It’s like removing too may letters from the alphabet and asking someone to write a full sentence. Sometimes it just can’t be done.
As mentioned previously the framework will choose the best encoder possible when generating our payload. However there are times when one needs to use a specific type, regardless of what Metasploit thinks. Imagine an exploit that will only successfully execute provided it only contains non-alphanumeric characters. The ‘shikata_ga_nai’ encoder would not be appropriate in this case as it uses pretty much every characters available to encode.
Looking at the encoder list, we see the ‘x86/nonalpha’ encoder is present.
If everything went according to plan, our payload will not contain any alphanumeric characters. But we must be careful when using a different encoder other than the default. As it tends to give us a larger payload. For instance, this one is much larger than our previous examples.
Our next option on the list is the ‘-f‘ switch. This gives us the ability to save our generated payload to a file instead of displaying it on the screen. As always it follows the ‘generate‘ command with file path.
By using the ‘cat‘ command the same way we would from the command shell, we can see our payload was successfully saved to our file. As we can see it is also possible to use more than one option when generating our shellcode.
Next on our list of options is the iteration switch ‘-i‘. In a nutshell, this tells the framework how many encoding passes it must do before producing the final payload. One reason for doing this would be stealth, or anti-virus evasion. Anti-virus evasion is covered in greater detail in another section of MSFU.
So let’s compare our bind shell payload generated using 1 iteration versus 2 iteration of the same shellcode.
The change is significant when comparing to all previous outputs. It’s slightly larger and our bytes are no where near similar. Which would, in theory, make this version of our payload less prone to detection.
We’ve spent lots of time generating shellcode from the start with default values. In the case of a bind shell the default listening port is 4444. Often this must be changed. We can accomplish this by using the ‘-o’ switch followed by the value we wish to change. Let’s take a look at which options we can change for this payload. From the msfconsole we’ll issue the ‘show options’ command.
Finally lets take a look at the NOP sled length and output format options. When generating payloads the default output format given is ‘ruby’. Although the ruby language is extremely powerful and popular, not everyone codes in it. We have the capacity to tell the framework to give our payload in different coding formats such as Perl, C and Java for example. Adding a NOP sled at the beginning is also possible when generating our shellcode.
First let’s look at a few different output formats and see how the ‘-t‘ switch is used. Like all the other options all that needs to be done is type in the switch followed by the format name as displayed in the help menu.
Looking at the output for the different programming languages, we see that each output adheres to their respective language syntax. A hash ‘#’ is used for comments in Ruby but in C it’s replaced with the slash and asterisk characters ‘/*’ syntax. Looking at all three outputs, the arrays are properly declared for the language format selected. Making it ready to be copy & pasted into your script.
Adding a NOP (No Operation or Next Operation) sled is accomplished with the ‘-s‘ switch followed by the number of NOPs. This will add the sled at the beginning of our payload. Keep in mind the larger the sled the larger the shellcode will be. So adding a 10 NOPs will add 10 bytes to the total size.