MASAPT: Multi-Agent System for Automated Penetration Testing

by do son · Published June 3, 2021 · Updated June 3, 2021

What is MASAPT?

It’s a proof-of-concept, multi-agent system, developed in Python, intended to be used for automating the process of penetration testing in a structured and intelligent way.

The ultimate goal is to make a working, flexible, distributed, CLI-based – pentesting tool that can be used for automating penetration testing tasks.

Current features:

Performing network scanning with Nmap
Performing basic SQL injection with SQLMap
Generating report with the results of performed exploits and reconnaissance

System overview 🔎

MASAPT system was envisioned to be modular, distributed, and pragmatic. Meaning that agents that make up the system are independent of the main process, upgradeable, and use existing, ‘battle-tested pentesting tools.

To achieve the goals envisioned, agents are developed as part of a three-tier model which is derived from standard pentest phases (planning – execution – post-execution). A high overview of a said model can be seen on Img1 below.

All theoretical concepts in this overview have already been implemented in code (apart from the idea for the future – Img 8.). These concepts should continue to be implemented in any future upgrades to the system.

Three-tier model

The main idea behind the three-tier model is to provide a framework to be used for organizing and classifying agents in this system.

The First-tier of the model contains the Explorer agent(s) which are tasked with conducting OSINT and gathering any useful intelligence about the target.

Second-tier contains the Coordinator agent and Exploit agents. The Coordinator is a single agent that decides which exploit agents are going to take part in the current testing. Exploit agents, as the name implies, are the ones running exploits – SQL injection, XSS, DoS, buffer overflow… There can be many of these exploit agents.

Third-tier contains the Reporter whose task is to collect all exploit data, results, data dumps from all exploit agents and summarise it in a final report. The report is then showed to the user and stored locally.

In the first image, thick arrows represent the flow of data in the model.

Img2 shows the same model as the first image but in greater detail – agents can be clearly seen in their respective tiers. The full arrows in this image again represent the flow of data in the model which consequently shows which agents are communicating with each other. It can be seen that the Explorer agent sends data to the Coordinator agent, who then, in turn, sends some data to the Exploit agents (SQLinjector, agent2, agent3). Finally, all the data that exploit agents gather is passed to the Reporter agent who then compiles it, summarises it, and presents it to the user.

It can also be seen that only Explorer and Exploit (SQLinjector) agents interact with the outside environment (Test target). This is represented with two-way dotted arrows.

Architecture

As mentioned earlier, one of the characteristics of the MASAPT system is for it to be distributed. One aspect of this has already been implemented seeing how all agents are implemented as independent programs, run by the main (masapt) script.

Img 3. shows how the current system was set up and tested. It can be seen that agents use the SPADE environment to communicate over the XMPP (ejabberd) server which is set up on the local system. Test target (SQLi Labs) is also set up on the local system. This setup is good for testing the system but it doesn’t show the full capability of MASAPT as a distributed system.

Img 4. on the other hand, shows one possible future implementation of MASAPT. It shows a distributed multi-agent system that uses XMPP to communicate and Docker to run across many different systems. Full arrows once again show the communication and data flow aspect of the system, showing how agents send and receive their data over a central XMPP server.

Reason for XMPP

The main reason for agents to communicate over XMPP is to provide a reliable, language-agnostic way for agents to communicate. With this approach, not all future agents have to be written in Python or even use the SPADE environment.

The reasoning behind this is that there may be some use case for a different system to be part of MASAPT in the future (ex. agents written in other programming languages). So this ‘XMPP approach’ is the best way to provide that kind of flexibility to the system.

Agent behaviour

Aside from its ability to communicate, behaviour is the second most important aspect of any agent. MASAPT agents and their behaviour is modeled with a set of states, which makes them finite state machines. SPADE environment has good support for creating finite state machines.

Diagrams below show all possible states an agent can be in at any moment in time. Diagrams also show which events cause an agent to switch to the next state. All future agents should be implemented in the same manner.

All future exploit agents (ex. DoS, XSS…) should be implemented using the Img 8. diagram as a template.