Lesson 1 - Metasploit Architecture

Metasploit Architecture

 

Filesystem And Libraries

The MSF filesystem is laid out in an intuitive manner and is organized by directory.

• data: editable files used by Metasploit
• documentation: provides documentation for the framework
• external: source code and third-party libraries
• lib: the 'meat' of the framework code base
• modules: the actual MSF modules
• plugins: plugins that can be loaded at run-time
• scripts: Meterpreter and other scripts
• tools: various useful command-line utilities

Libraries

Rex

• The basic library for most tasks
• Handles sockets, protocols, text transformations, and others
• SSL, SMB, HTTP, XOR, Base64, Unicode

Msf::Core

• Provides the 'basic' API
• Defines the Metasploit Framework

Msf::Base

• Provides the 'friendly' API
• Provides simplified APIs for use in the Framework 

Modules And Locations

Metasploit, as presented to the user, is composed of modules.

Exploits

• Defined as modules that use payloads
• An exploit without a payload is an Auxiliary module

Payloads, Encoders, Nops

• Payloads consist of code that runs remotely
• Encoders ensure that payloads make it to their destination
• Nops keep the payload sizes consistent.

Modules Locations

Primary Module Tree

• Located under /opt/metasploit/msf3/modules/

User-Specified Module Tree

• Located under ~/.msf4/modules/
• This location is ideal for private module sets

Loading Additional Trees at Runtime

• Pass the -m option when running msfconsole (msfconsole -m)
• Use the loadpath command within msfconsole

Metasploit Object Model

In the Metasploit Framework, all modules are Ruby classes.

• Modules inherit from the type-specific class
• The type-specific class inherits from the Msf::Module class
• There is a shared common API between modules

Payloads are slightly different.

• Payloads are created at runtime from various components
• Glue together stagers with stages 

Mixins And Plugins

A quick diversion into Ruby.

• Every Class only has one parent
• A class may include many Modules
• Modules can add new methods
• Modules can overload old methods
• Metasploit modules inherit Msf::Module and include mixins to add features.

Metasploit Mixins

Mixins are quite simply, the reason why Ruby rocks.

• Mixins 'include' one class into another
• This is both different and similar to inheritance
• Mixins can override a class' methods

Mixins can add new features and allows modules to have different 'flavors'.

• Protocol-specific (ie: HTTP, SMB)
• Behavior-specific (ie: brute force)
• connect() is implemented by the TCP mixin
• connect() is then overloaded by FTP, SMB, and others.

Mixins can change behavior.

• The Scanner mixin overloads run()
• Scanner changes run() for run_host() and run_range()
• It calls these in parallel based on the THREADS setting
• The BruteForce mixin is similar

class MyParent
     def woof
          puts “woof!”
     end
end

class MyClass < MyParent
end

object = MyClass.new
object.woof() => “woof!”

================================================================

module MyMixin
     def woof
          puts “hijacked the woof method!”
     end
end

class MyBetterClass < MyClass
     include MyMixin
end

Metasploit Plugins

Plugins work directly with the API.

• They manipulate the framework as a whole
• Plugins hook into the event subsystem
• They automate specific tasks which would be tedious to do manually

Plugins only work in the msfconsole.

• Plugins can add new console commands
• They extend the overall Framework functionality