Metasploit Payloads Explained - Part 1
Payload selection is something that rarely gets talked about in detail. Most PoCs just use calc.exe, netcat, or some kind of socket. The vast majority of Metasploit tutorials, videos and documentation use the windows/meterpreter/reverse_tcp payload which is only one of 224 possible payloads. Here is a little disclaimer: While the payloads in Metasploit don’t get updated as much as other parts of Metasploit, this is a point in time documentation of them (June 23, 2011) and the payloads available in Metasploit are constantly changing. I challenge you to continue to do a ‘show payloads’ and see what’s new.
If you issue ‘show payloads’ at the base of Metasploit’s console (msf>), it will show you every payload that Metasploit has available. However, exploit module writers can help the user out a bit with their selection by putting special limiters inside of their module. These limiters can be as specific as pointing out a specific payload, or as broad as specifying that it will only work with a ‘windows’ payload. For a decent example of this in action check out the JBoss ‘bshdeployer’ exploit module (modules/exploits/multi/http/jboss_bshdeployer.rb).
The payloads Metasploit has are broken down into ‘staged’, ‘stagers’, and ‘**singles **(also known as Inline)’. The difference between ‘staged’ and ‘stagers’ is pretty simple, ‘staged’ payloads use tiny ‘stagers’ to be able to fit into small exploitation spaces. During exploitation the exploit developer often has a very limited amount of memory they can manipulate through the programs inputs that they are exploiting. The stagers go in this space and their only job is to pull down the rest of the ‘staged’ payload. The downside to these types of payloads is they require a connection to something that will shovel them the rest of the payload. Inline payloads or ‘singles’ don’t have this problem. They are self contained and do what they are designed to do without any assistance.
All of the payloads in Metasploit use the one, the only, Multi Handler. I call it that because of how I call it:
|
|
It is a fitting title though as it is equipped to handle every single payload inside of Metasploit no matter what the architecture or type of connection being made. It knows how to deal with each type of payload because you tell it what to expect, but that doesn’t take away from the fact that in this single utility lies the crucial stepping stone for all of Metasploit’s exploitation.
The structure of most payloads tell you exactly what they do, but not always. If it says in the description that it’s ‘Inline’ that means it is a single, if it says ‘Stager’ that means it’s staged. Lets break a few down of the lesser known ones:
cmd/windows/adduser- This is a single that executes ’net user /add’ with the username and password you specify. This one doesn’t say that it’s ‘Inline’ but all of the ‘cmd/’ or ‘/exec’ payloads are singles.osx/armle/vibrate- A single that when executed on an iPhone, it vibrates.generic/debug_trap- Trips a debugger if it’s attached to the process (sends a single xCC ‘break’ byte)
One thing that isn’t immediately obvious is another marker of staged vs. singles:
|
|
The difference between these two payloads isn’t obvious other than the fact that one has an underscore ‘_’ instead of a forward slash ‘/’. The one with the underscore means it’s a single while the other is staged. But the architecture of the naming convention is a bit complicated. Most stick to OS/ARCHITECTURE/TYPE/PAYLOAD where a slash instead of an underscore between TYPE and PAYLOAD would signify the difference we just talked about. But not all payloads stick to this format. You can even go crazy and actually look in the directory: msfdirectory/modules/payloads/ - everything in the singles directory.. hmmm yup, is a single.
Singles are great for fire and forget, I’ve used as payloads for USB sticks (so the machine didn’t have to have a connection to do what I needed) all the way to a pretty sneaky persistence method. One that I used quite often at CCDC was with the payload: ‘windows/download_exec’. The only option this single has is ‘URL’. We would put something like http://www.redteam.com/evil.exe and generate the binary:
(Yes you can use msfpayload, or msfvenom on the command line to generate payloads, but I like to stay inside of msfconsole)
Then set that to auto start when someone logs in with something like:
|
|
Now all we had to do is wait for logins. If they happened to find our evil.exe binary (which download_exec makes it ‘a.exe’ and puts it in System32), and blocked our IP, all we had to do in replace evil.exe on our web server and wait for it to download the new one. A crude form of persistence, but it worked well.
I’m going to end this with a list of all the payloads… hopefully for all you tab completion lazy bums this might be the first time you’ve actually have taken a second to look around. In the next post I’ll be going into Meterpreter, the BEST payload in my humble-totally-unbiased opinion ;), with a bit of pivoting thrown in for good measure.
