49 lines
1.7 KiB
Plaintext
49 lines
1.7 KiB
Plaintext
Auxiliary Module Design
|
|
-----------------------
|
|
|
|
The goal of this document is to define the requirements and basic
|
|
implementation of Metasploit v3.0 Auxiliary Modules. Auxiliary modules have a
|
|
unique role in the Framework in that they can do just about anything.
|
|
Auxiliary modules work similar to exploits, in that the user selects a module,
|
|
configures, and launches it, but differs in that they do not execute arbitrary
|
|
code on target systems.
|
|
|
|
|
|
Design Goals
|
|
------------
|
|
|
|
Auxiliary modules should be capable of performing reconnaisance activities,
|
|
such as sending probes or listening to the network, and exporting the data
|
|
into a persistent storage system accessible to the rest of the Framework. Not
|
|
all auxiliary modules produce this type of data, some may perform intrusive
|
|
actions, such as file retrieval or modifying access credentials.
|
|
|
|
An Auxiliary module has the ability to define new commands and then process
|
|
these commands. Any user interface that sypports Auxiliary modules needs to
|
|
take into account this fact and allow these optional commands to be accessed.
|
|
|
|
Unlike exploits, auxiliary modules do not use Targets, instead they support
|
|
what we call Actions. An Action is an option, that when set, causes the
|
|
auxiliary module to perform a selected task. Between the extensible command
|
|
set and the Actions system, a single auxiliary module is capable performing an
|
|
almost infinite number of tasks.
|
|
|
|
An example would be a module that performs various tasks against a Microsoft
|
|
SQL Server. This module would only support the default command of 'run', but
|
|
could allow the user to send a UDP probe and display the data, perform an
|
|
account brute force, or scan all open ports for an exposed MSSQL DCERPC
|
|
interface.
|
|
|
|
|
|
|
|
|
|
|
|
Storage
|
|
-------
|
|
|
|
|
|
|
|
|
|
Requirements
|
|
------------
|