-
Notifications
You must be signed in to change notification settings - Fork 0
Previous Approaches & Implementations
Every Metasploit user knows that versatile is paramount, but excessive is meaningless. The meaning of "framework" in Metasploit is subtile, and extending it with a GUI component consequently is. The same thing applies to numerous tools and frameworks in computer security.
-
Armitage, the old GUI that seems not to be supported anymore, would bring some sort of context-sentivity for exposing Metasploit tools, sessions, modules and consoles. However, the graphical representation of the network would be way too primary, with only a small variety of figures. In addition, Armitage would only CONSUME data from the Metasploit Database, and would not expose it to other tools (except from db_nmap).
-
Pro Consoles obviously offer a much broader toolset than the Metasploit Framework. However, the approach of these tools with regard to network data visualization is not perfect. It is mainly composed of lists, processed and acted upon with various statistical tools, as well as systematic vulnerability testing capacities, which are very noisy. This approach is only possible for the owner of the system, because he knows how to explain the noise. He does not have time to try every single path with a human eye. Therefore, and even if these tools have an undeniable use case, they are not fully adapted to red teams. As well, but to a smaller extent than Armitage, professional software might not expose their data to external tools while keeping it in their own GUI.
Several attempts (Sploitego, MSploitego) have been made at interfacing Metasploit with Maltego. They represents dozens, hundreds of thoughtful iterations toward this goal. They are definitely an unvaluable help for this project. However, building the optimal interface is complex, and requires both careful planning and the good libraries. These attempts might have lacked either:
- The Metasploit Web Service API (JSON), for exhaustive and versatile consumption of the Metasploit Database content, with easy-to-manage auth.
- Easy-to-use (Python or JSON) RPC librairies for session/console management.
-
As a consequence of the lack of existing libraries, the granularity of interactions with Metasploit database was weak. Example: A database could only output all hosts -or services- at a time, with no filtering possibility. There was also no possibility of modifying the data in the DB directly from Maltego. See "2/ Database Interaction" in Metasploit.
-
Sub-optimal fusion of Metasploit workspaces with different entities in Maltego (
IPv4Address,Netblock,Host), which leads to a flawed and unflexible representation of a network's topology (functional, geographical, etc). Example: See "1/ Workspace Integration" in Metasploit. -
Unclear/unbounded integration of Metaploit's object diversity into Maltego's Entity model. Consequently, efficiently consuming (get/post) Metasploit DB was complicated, and would have been more as the number of entities/transforms/ tools would grow. Example: How to represent the variety of operating systems, websites, services, while not making their management difficult, and their presence useful ?
- Abusive and unflexible integration of non-MSF tools into the set of transforms, which has the effect of excessively "scoping" these entities and their transforms. This results in Metasploit entities in Maltego that cannot benefit from other transform sets. As well, integration would often be about vulnerability scanners which, as said above, are not primordial tools to integrate first, as they do not really fit the constraints of red teams in terms of discretion.