Although single-stage shellcode can do most everything needed, the ability to extend a load with new connection options such as tunnel response over ssl makes multistage pay-loads attractive.
Multistage shell code carries out the same task as single-stage shellcode; it is just more abstracted for ease of use and extendibility.There are two parts to a multistage page in Metasploit.The first part is a bit of code that performs a basic task; the second part is single-purpose code that handles communication between the attacker and code on the victim’s machine.
The stages directory is where the initial building blocks for multistaged shellcode reside.
These snippets of code are generally individual tasks.These tasks could be as simple as adding a user or spawning a shell.These tasks are lightweight and do not have any commu-nication code.
Scripts in the stagers directory provide the new features, such as communication abilities.
These features are added by reading in the base code from the stages directory and then lay-ering in new code from the stagers directory. Both the stager and the stages work together to carry out a task. Examining the resulting payloads should cement the operations.
The best script for examination of a multistage payload is the following shell script:
<MSF HOME>/modules/payloads/stages/windows/shell.rb.
This small, simple script is a good example because it implements all the different stager functionality.
This script will open a command prompt on a target Windows machine. Using msfpay-load on windows/shell/bind_tcp will yield two outputs.The first output will be the con-tents of <MSF HOME>/modules/payloads/stagers/windows/bind_tcp.rb with the second output being the contents of shell.rb.
Looking at the list of payloads you will see several different windows/shell versions.
windows/shell/bind_tcp windows/shell/find_tag windows/shell/reverse_http windows/shell/reverse_ord_tcp windows/shell/reverse_tcp
Each version you choose will use a different layer from the stagers directory.The stager is controlled by its corresponding script in the <MSF HOME>/lib/msf/core/handler.
In order to add a new stager, you must first create a script in the <MSF
HOME>/lib/msf/core/handler directory. For the example shown in Figure 5.7, the new stager is kept in new_stager.rb. In new_stager.rb a module is declared as “NewTcp.”
Next <MSF HOME>/modules/payloads/stagers/windows/new_stager.rb is created.
Figure 5.7Both of the New_stager.rb Files in Their Proper Places
The new_stager.rb file in the stagers directory contains the following script:
1 require 'msf/core'
10 def initialize(info = {})
11 super(merge_info(info,
12 'Name' => 'New stager example',
13 'Version' => '$Revision: 4571 $',
14 'Description' => 'Shows how to add new stager',
15 'Author' => 'david',
Line 7 begins the declaration of the test module, NewTcp.This module is also declared in the <MSF HOME>/lib/msf/core/handler/new_stager.rb file. Lines 8 and 9 include the Stager and Windows mixins. Line 10 begins the initialization through line 26. Line 19 declares what handler is responsible for this stager. Line 21 contains the beginning of the actual Stager code with line 23 beginning the very simple payload.
The result is now the stager_example option shows up for every multistage windows shellcode (see Figure 5.8).
Figure 5.8The stager_example Option
The new stager_example stager is showing up for all the multistage Windows shellcode.
Of course, the only thing this stager does is add a few NOPs and execute an INT 0xCC, which is a trap to a debugger on Windows platforms.This is verifiable by running the msfpayloadcommand and examining the output of this command (see Figure 5.9).
When called up the stager_example just outputs a simple string of hex. Note the Stage 1 output.
Options can be defined in the stager initialization as well as offsets to important parts of the code such as connection structures.
Figure 5.9The Output of Running the msfpayload Command
With a successful stager loaded, the next logical step would be to add a stage.This is rather simple with the script for a test stage shown in the following example:
1 require 'msf/core'
2 module Msf 3 module Payloads 4 module Stages 5 module Windows
6 module NewShellExec
7 include Msf::Payload::Windows
8 def initialize(info = {})
9 super(merge_info(info,
10 'Name' => 'StageAddTest',
11 'Version' => '$Revision: 4571 $',
12 'Description' => 'test for adding a new
stage',
13 'Author' => 'dave',
14 'License' => MSF_LICENSE,
15 'Platform' => 'win',
16 'Arch' => ARCH_X86,
17 'Session' =>
Msf::Sessions::CommandShell,
18 'Stage' =>
19 {
20 'Payload' =>
21 "\x90\x90\x90\xcc"
22 }
23 ))
24 end
25 end
26 end end end end.
The simple script begins primarily at line six with the declaration of a new module called NewShellExec. Line seven includes the Windows mixin. Line eight begins the initial-ization section. Line 17 describes what kind of shell to start if the exploit succeeds. Line 20 and 21 reveal the payload to be a simple NOP sled with an INT 3 at the end. Calling this stage with the custom stager will produce an output of both modules.This shows that the code stager code, stager_example, is just overlaid on top of the newstage code (see Figure 5.10).
Figure 5.10Adding a Stage