diff --git a/docs/2020.4.1/example.md b/docs/2020.4.1/example.md
deleted file mode 100644
index 46a140591df363bae1deef6eb7af0cb5c40d9260..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/example.md
+++ /dev/null
@@ -1,216 +0,0 @@
-# Example execution
-
-There are multiple steps to be completed before the whole loading and executing Run can be done. As was said earlier, there are more components in Cryton:
-
-1. **Cryton Core - REST API**
-2. **Cryton Core - Scheduler**
-3. **Cryton Core - Listener**
-4. **Cryton Worker**
-5. **Cryton CLI**
-
-## 1. Cryton Core
-### Using Docker Compose
-If you've installed Cryton Core using Docker Compose installation guide, then you are all set. However just to be sure:
-
-
-
-1. Go to Cryton Core directory `cd cryton-core`.
-2. Check if **all** Cryton Core components are UP `docker-compose ps`.
-3. If some are restarting use `docker-compose restart` or if they are down use `docker-compose start`.
-4. If you can't access REST API restart it `docker-compose restart cryton_app`.
-
-### Manually
-First go to Cryton Core directory `cd cryton-core` and enter the virtual environment `pipenv shell`.
-
-Now you have to start the Core itself, which provides **REST API**. This it the API the CLI uses.
-*Note: This is a debug/testing way for running the REST API server. For production see [WSGI](installation.md#running-in-apache-wsgi).*
-
-```
-cryton-manage runserver
-```
-
-To override default address and port use:
-```
-cryton-manage runserver address:port
-```
-
-Output should look like this:
-```
-Watching for file changes with StatReloader
-Performing system checks...
-
-Starting development server at http://127.0.0.1:8000/
-Quit the server with CONTROL-C.
-```
-
-Starting Scheduler is also really simple:
-```
-cryton-manage startscheduler
-```
-
-Output should look like this:
-```
-Scheduler started
-Looking for jobs to run
-Starting scheduler service. Listening on localhost:12345
-server started on [127.0.0.1]:12345
-Got []
-No jobs; waiting until a job is added
-```
-
-Lastly we have to start Listener to be able to communicate with Worker:
-```
-cryton-manage startlistener
-```
-
-At the end you should see this line:
-```
- [*] Waiting for messages. To exit press CTRL+C
-```
-
-## 2. Modules
-To be able to execute attack modules we have to copy them into the same directory as Cryton Worker
-has declared in settings (`CRYTON_WORKER_MODULES_DIR=/opt/cryton-worker/modules/`).
-
-If we use the default path for example:
-~~~~
-cp path/to/module/dir /opt/cryton-worker/modules/
-~~~~
-**All the requirements are checked and installed on Worker's start up if `--install-requirements` flag is used.**
-
-**IMPORTANT: In *plan template* in *attack_module* parameter specify relative path to module directory only (for example: `infrastructure/scan/mod_scan`).**
-
-## 3. Cryton Worker
-### Manually
-First go to Cryton Worker directory `cd cryton-worker` and enter the virtual environment `pipenv shell`.
-
-Now you have to update Worker settings, especially RabbitMQ address and credentials using `export CRYTON_WORKER_CUSTOM_VAR=custom_value`.
-To see all variables use `export`.
-
-Once you're done you can start Cryton Worker.
-```
-cryton-worker start
-```
-
-If you see `Successfully created connection.` you're all set.
-
-## Cryton Cli
-Now we can start using CLI to control Cryton.
-To use CLI go to Cryton CLI directory `cd cryton-cli`, enter the virtual environment `pipenv shell` and type `cryton-cli`.
-
-Localhost and port 8000 are used as default REST API address/port.
-To override it use *-H* and *-p* options.
-
-```
-cryton-cli -H 127.0.0.1 -p 8000
-```
-
-Create a Plan template using a file containing the desired plan YAML.
-```yaml
----
-plan:
- name: Example scenario
- owner: your name
- stages:
- - name: stage-one
- trigger_type: delta
- trigger_args:
- seconds: 5
- steps:
- - name: scan-target
- is_init: true
- attack_module: mod_nmap
- attack_module_args:
- target: "{{target}}"
- ports:
- - 22
- next:
- - type: result
- value: OK
- step: ssh-bruteforce
- - name: ssh-bruteforce
- attack_module: mod_hydra
- attack_module_args:
- target: "{{target}}"
- username: "{{username}}"
- password: mypass
-```
-```
-cryton-cli plan-templates create example-plan.yml
-```
-
-Output:
-```
-Template successfully created! ({'url': '', 'id': 1, 'file': ''}).
-```
-
-Create a Plan instance using saved Template with ID 1.
-```
-cryton-cli plans create 1
-```
-
-To create a Plan instance using template and inventory file simply specify `-i` parameter (for example`-i hosts-file`).
-For example with inventory file `inv.json` containing `{"username": "admin"}` you would use `cryton-cli plans create 1 -i inv.json` to fill the username variable.
-
-Output:
-```
-Plan Instance successfully created! ({'plan_model_id': 1, 'link': ''}).
-```
-
-To be able to execute Plans (Runs) we have to define Worker (address, name and optionally prefix).
-Prefix will be used in worker. Either the prefix is custom or is created by joining name and address.
-In this case it would be: `name_address`.
-```
-cryton-cli workers create address name -p customPrefix
-```
-
-Output:
-```
-Worker successfully created! ({'worker_model_id': 1, 'link': ''}).
-```
-
-Create a Run by choosing Plan Instance and providing list of Workers for execution.
-
-```
-cryton-cli runs create 1 1
-```
-
-Output:
-```
-Run successfully created! ({'run_model_id': 1, 'link': ''}).
-```
-
-To provide additional inventory file (variables to fill missing target variable) to PlanExecution instance with ID *1*
-create inventory file containing `{"target": "localhost"}` and use command:
-```
-cryton-cli execution-variables create 1 inventory-file
-```
-If you would want a second worker with different target variable, you just have to create second Worker
-(it is impossible to append worker to created Run) and create execution variables for the second PlanExecution.
-
-Output:
-```
-Execution variable(s) successfully created! ([1]).
-```
-
-Execute created Run to start the execution tree.
-
-```
-cryton-cli runs execute 1
-```
-
-Output:
-```
-Run successfully executed! (Run 1 was executed.).
-```
-
-Anytime during execution report can be generated, which also complies to YAML format, and it contains list of Stages/Steps, their success and output or, if available, error message.
-
-```
-cryton-cli runs report 1
-```
-
-Output:
-```
-Successfully created Run's report! (file saved at: /tmp/report_run_1_2020-06-08-10-15-00-257994_xdQeV)
-```
\ No newline at end of file
diff --git a/docs/2020.4.1/execution.md b/docs/2020.4.1/execution.md
deleted file mode 100644
index 53669de12e3bfd70f2c1d527085c79541ad7e913..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/execution.md
+++ /dev/null
@@ -1,11 +0,0 @@
-## Execution
-
-There are special kinds of objects called *Executions* for every unit in Attack scenario:
-
-* **PlanExecution**
-* **StageExecution**
-* **StepExecution**
-
-These are not objects that need to be created by you - instead they are created when their respective unit is executed. This way a history and results of each and every execution can be stored.
-
-Every Execution object stores a start and finish time, so it is easy to count running times of each unit. With Steps the Execution is also a place where the output and results from attack modules is stored.
\ No newline at end of file
diff --git a/docs/2020.4.1/install-core.md b/docs/2020.4.1/install-core.md
deleted file mode 100644
index 72b6b6b8bc81de11c013c78552af8c305ea9dcc2..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/install-core.md
+++ /dev/null
@@ -1,202 +0,0 @@
-## Core Installation
-
-Cryton Core uses environment variables for it's settings.
-
-~~~~
-CRYTON_RABBIT_USERNAME=admin
-CRYTON_RABBIT_PASSWORD=mypass
-CRYTON_RABBIT_SRV_ADDR=cryton_rabbit
-CRYTON_RABBIT_SRV_PORT=5672
-CRYTON_DB_NAME=cryton
-CRYTON_DB_USERNAME=cryton
-CRYTON_DB_PASSWORD=cryton
-CRYTON_DB_HOST=cryton_db
-CRYTON_SCHEDULER_LHOSTNAME=cryton_scheduler
-CRYTON_SCHEDULER_LPORT=12345
-Q_ATTACK_RESPONSE_NAME=cryton_core.attack.response
-Q_CONTROL_RESPONSE_NAME=cryton_core.control.response
-Q_EVENT_RESPONSE_NAME=cryton_core.event.response
-CRYTON_DEBUG=False
-~~~~
-
-### Using docker-compose (recommended)
-
-Go into Cryton Core directory and run docker-compose, which will pull, build and start all necessary docker images.
-
-**If you've updated either docker-compose file or environment variables please check that they correspond.**
-
-For production environment, there are some other options needed (such as publishing ports to public IP addresses, persistent database data volume etc. For production deployment, use:
-
-~~~~
-user@localhost:~ /cryton-core $ docker-compose -f docker-compose.prod.yml up -d
-~~~~
-
-Otherwise use the default docker-compose file:
-
-~~~~
-user@localhost:~ /cryton-core $ docker-compose up -d
-~~~~
-
-
-This process might take a while, especially if it is the first time you run it - image must be built.
-After a while you should see something like this:
-
-~~~~
-Creating db ... done
-Creating rabbit ... done
-Creating scheduler ... done
-Creating listener ... done
-Creating app ... done
-~~~~
-
-After that, you should run database migrations:
-
-~~~~
-user@localhost:~ /cryton-core $ docker-compose exec cryton_app cryton-manage makemigrations cryton_rest_api
-user@localhost:~ /cryton-core $ docker-compose exec cryton_app cryton-manage migrate
-~~~~
-
-Everything should be set. Check if the installation was successful by either installing Cryton CLI or testing REST API with curl:
-
-~~~~
-curl localhost:8000
-~~~~
-
-and the response should be:
-
-~~~~
-{"runs":"http://localhost:8000/cryton/api/v1/runs/","plans":"http://localhost:8000/cryton/api/v1/plans/","plan_executions":"http://localhost:8000/cryton/api/v1/plan_executions/","stages":"http://localhost:8000/cryton/api/v1/stages/","stage_executions":"http://localhost:8000/cryton/api/v1/stage_executions/","steps":"http://localhost:8000/cryton/api/v1/steps/","step_executions":"http://localhost:8000/cryton/api/v1/step_executions/","workers":"http://localhost:8000/cryton/api/v1/workers/"}
-~~~~
-
-If the REST API won't respond try restarting it:
-
-~~~~
-user@localhost:~ /cryton-core $ docker-compose restart cryton_app
-~~~~
-
-### Manual installation
-
-Cryton Core uses PostgreSQL as it's internal database, so it must be installed and started on your system.
-
-**Installation is tested and presented under *sudo* user. Please make sure you have `sudo` privileges.**
-
-#### Requirements
-
-- postgresql
-- rabbitmq-server
-- libpq5
-- libpq-dev
-- python3.7 (3.7 and 3.8 are tested versions)
-- pipenv (optional)
-
-#### Installation
-
-First you need to create database and database tables Cryton internal storage. This database is also used for scheduler and tasks persistence:
-
-~~~~
-su postgres
-psql -c "CREATE DATABASE cryton;"
-psql -c "CREATE USER cryton WITH PASSWORD 'cryton';GRANT ALL PRIVILEGES ON DATABASE cryton TO cryton;ALTER DATABASE cryton OWNER TO cryton; ALTER USER cryton CREATEDB;";
-exit
-~~~~
-
-In order to start Core's listener you have to install `rabbitmq-server` and start it.
-
-~~~~
-apt install rabbitmq-server
-service rabbitmq-server start
-~~~~
-
-Go into Cryton Core directory. You can use pipenv for creating virtual environment and enter it.
-
-```
-cd cryton-core
-pipenv install # has to be virtual environment with python3.7 (or 3.8)
-pipenv shell
-```
-
-Use setup.py to install the package.
-
-**You have to use python setup.py to install Core project, as it needs to copy some files into /etc
-and /home/.cryton directories. If installed using pip, this does not happen and you would have to
-copy this files by hand.**
-
-```
-python setup.py install
-```
-
-Use _develop_ if you wish to directly (locally) modify the code:
-
-```
-python setup.py develop
-```
-
-Now update Cryton's settings.
-
-~~~~
-export CRYTON_DB_HOST=localhost
-export CRYTON_RABBIT_SRV_ADDR=localhost
-export CRYTON_SCHEDULER_LHOSTNAME=localhost
-export CRYTON_RABBIT_USERNAME=guest
-export CRYTON_RABBIT_PASSWORD=guest
-~~~~
-
-
-After successful installation the only thing needed is Django _migration_ for creating default tables in Cryton database:
-
-```
-cryton-manage makemigrations cryton_rest_api
-cryton-manage migrate
-```
-
-To check if installation was successfull try to start the REST API:
-*Note: This is a debug/testing way for running the REST API server. For production see [WSGI](#running-in-apache-wsgi).*
-
-```
-cryton-manage runserver
-```
-
-You should see:
-
-```
-Starting server at http://127.0.0.1:8000/
-Quit the server with CONTROL-C.
-```
-
-## Running in apache (WSGI)
-
-1. Create site in sites-available (eg. **001-cryton.conf**)
- **(replace path to virtualenv with your current - you can get it by running `pipenv --venv`)**
-
-```
-<VirtualHost *:80>
-WSGIDaemonProcess cryton python-home=/root/.local/share/virtualenvs/kypo2-cryton-_aTpEfuL python-path=/root/.local/share/virtualenvs/kypo2-cryton-_aTpEfuL/lib/python3.7/site-packages/cryton-1.0-py3.7.egg/cryton
-WSGIProcessGroup cryton
-WSGIScriptAlias /cryton /root/.local/share/virtualenvs/kypo2-cryton-_aTpEfuL/lib/python3.7/site-packages/cryton-1.0-py3.7.egg/cryton/wsgi.py
-
-# Alias for Django RESTframework static files
-Alias /static /root/.local/share/virtualenvs/kypo2-cryton-_aTpEfuL/lib/python3.7/site-packages/djangorestframework-3.9.4-py3.7.egg/rest_framework/static
-# Alias for Swagger static files
-Alias /static /root/.local/share/virtualenvs/kypo2-cryton-_aTpEfuL/python3.7/site-packages/drf_yasg/static
-
- <Directory /root/.local/share/virtualenvs/kypo2-cryton-_aTpEfuL/lib/python3.7/site-packages/cryton-1.0-py3.7.egg/cryton/>
- Require all granted
- </Directory>
- <Directory /root/.local/share/virtualenvs/kypo2-cryton-_aTpEfuL/lib/python3.7/site-packages/rest_framework>
- Require all granted
- </Directory>
-</VirtualHost>
-```
-
-2. Enable site
-
-```
-root@kali:/etc/apache2# a2ensite 001-cryton.conf
-```
-
-3. Reload apache
-
-```
-root@kali:/etc/apache2# systemctl reload apache2
-```
-
diff --git a/docs/2020.4.1/install-modules.md b/docs/2020.4.1/install-modules.md
deleted file mode 100644
index efc0ca30cd16625b60bb431d83749bf267797dcb..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/install-modules.md
+++ /dev/null
@@ -1,15 +0,0 @@
-## Modules installation
-
-Attack modules are executed by Cryton Worker, so they have to be accessible by it.
-To be able to use them, change the directory in Worker's configuration (environment variable ```CRYTON_WORKER_MODULES_DIR``` ) to the path of your cryton-modules project (or any other directory where you keep the modules).
-
-
-Example:
-
-~~~~
-user@localhost:/home/user $ git clone git@gitlab.ics.muni.cz:cryton/cryton-modules.git
-user@localhost:/home/user $ export CRYTON_WORKER_MODULES_DIR=/home/user/cryton-modules/modules
-~~~~
-
-As mentioned above, Cryton Worker is used for validating and executing modules and in order for them to work you have to install their requirements. To do that you either install them manually inside Cryton Worker's environment or you use Cryton Worker's CLI: `cryton-worker start --install-requirements`. If this flag is specified each *requirements.txt* file inside the Worker's modules directory will be check and installed.
-
diff --git a/docs/2020.4.1/install-worker.md b/docs/2020.4.1/install-worker.md
deleted file mode 100644
index ea2ac35965c99218a258c7723b739783fa163058..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/install-worker.md
+++ /dev/null
@@ -1,134 +0,0 @@
-## Worker Installation
-
-For this installation we are assuming installation on the same machine. Please update variables for your use case.
-
-Cryton Worker uses environment variables for it's settings.
-
-~~~~
-CRYTON_WORKER_MODULES_DIR=/opt/cryton-worker/modules/
-CRYTON_WORKER_DEBUG=False
-CRYTON_WORKER_MSFRPCD_PASS=toor
-CRYTON_WORKER_MSFRPCD_USERNAME=msf
-CRYTON_WORKER_MSFRPCD_PORT=55553
-CRYTON_WORKER_MSFRPCD_SSL=False
-CRYTON_WORKER_RABBIT_USERNAME=admin
-CRYTON_WORKER_RABBIT_PASSWORD=mypass
-CRYTON_WORKER_RABBIT_SRV_ADDR=CHANGE_ME
-CRYTON_WORKER_RABBIT_SRV_PORT=5672
-CRYTON_WORKER_RABBIT_WORKER_PREFIX=CHANGE_ME
-CRYTON_WORKER_CORE_COUNT=AUTO
-~~~~
-
-### Manual installation (recommended)
-
-**Installation is tested and presented under *sudo* user. Please make sure you have `sudo` privileges due to the need to enter /etc directory.**
-
-#### Requirements
-
-- python3.8 (tested version)
-- pipenv (optional)
-
-#### Installation
-
-Go into Cryton Worker directory, create python environment and enter it.
-
-~~~~
-cd cryton-worker
-pipenv install
-pipenv shell
-~~~~
-
-Update Worker's settings:
-`CRYTON_WORKER_RABBIT_SRV_ADDR` (with the actual address of RabbitMQ server),
-`CRYTON_WORKER_RABBIT_WORKER_PREFIX` (with desired prefix that will be used to communicate with the Worker),
-`CRYTON_WORKER_RABBIT_USERNAME` (RabbitMQ username) and `CRYTON_WORKER_RABBIT_PASSWORD` (RabbitMQ password).
-
-~~~~
-export CRYTON_WORKER_RABBIT_SRV_ADDR=localhost
-export CRYTON_WORKER_RABBIT_WORKER_PREFIX=worker_prefix
-export CRYTON_WORKER_RABBIT_USERNAME=guest
-export CRYTON_WORKER_RABBIT_PASSWORD=guest
-~~~~
-
-And finally install Worker.
-
-**You have to use python setup.py to install Worker project, as it needs to copy some files into /etc
-directory. If installed using pip, this does not happen and you would have to copy this files by hand.**
-
-~~~~
-python setup.py install
-~~~~
-
-Use _develop_ if you wish to directly (locally) modify the code:
-
-```
-python setup.py develop
-```
-
-Everything should be set. Check if the installation was successful start the Worker:
-
-~~~~
-cryton-worker
-~~~~
-
-To start Worker use `cryton-worker start` and you should see something like:
-~~~~
-Worker is running, waiting for connections...
-Successfully created connection.
-~~~~
-
-If you see an error. Please check if Rabbit variables are correct and start Worker again.
-
-### Using docker-compose
-
-#### Installation
-**NOTICE: Following guide won't describe how to install or mount applications used by modules.**
-
-
-Go into Cryton Worker directory and update .env file.
-Especially `CRYTON_WORKER_RABBIT_SRV_ADDR` (with the actual address of RabbitMQ server),
-`CRYTON_WORKER_RABBIT_WORKER_PREFIX` (with desired prefix that will be used to communicate with the Worker),
-`CRYTON_WORKER_RABBIT_USERNAME` (RabbitMQ username) and `CRYTON_WORKER_RABBIT_PASSWORD` (RabbitMQ password).
-
-~~~~
-cd cryton-worker/
-vi .env
-~~~~
-
-Run docker-compose, which will pull, build and start all necessary docker images.
-
-**If you've updated either docker-compose file or environment variables please check that they correspond.**
-
-**For successful start RabbitMQ server must be running!**
-
-~~~~
-docker-compose up -d
-~~~~
-
-This process might take a while, especially if it is the first time you run it - image must be built.
-After a while you should see something like this:
-
-~~~~
-Creating cryton_worker ... done
-~~~~
-
-Everything should be set. Check if the installation was successful:
-
-~~~~
-docker-compose ps
-~~~~
-
-You should see something like:
-
-~~~~
- Name Command State Ports
----------------------------------------------
-cryton_worker cryton-worker Up
-~~~~
-
-If is in state `Restarting`, something went wrong. Please check if Rabbit address is correct and restart Worker.
-
-~~~~
-docker-compose restart worker
-~~~~
-
diff --git a/docs/2020.4.1/installation.md b/docs/2020.4.1/installation.md
deleted file mode 100644
index 5348f20f86e1cc04fdf3bf8cb5f333f08ae886f1..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/installation.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# Requirements
-For being able to execute the attack scenarios, you need to install the **Cryton core**,
-**Cryton worker** package and copy the **modules** you wish to execute in the attack scenarios
-into directory specified in *Cryton Worker*.
-
-So far the only supported OS is Kali Linux with version 2020.3 (and maybe newer).
-
-**Required packages**
-
-- docker.io
-- docker-compose
-
-#### Installation
-
-First make sure you have Docker and Docker Compose installed:
-
-~~~~
-user@localhost:~ $ sudo apt install docker.io docker-compose
-~~~~
-
-Add yourself to the group docker so you can work with docker CLI without sudo:
-
-~~~~
-user@localhost:~ $ sudo groupadd docker
-user@localhost:~ $ sudo usermod -aG docker $USER
-user@localhost:~ $ newgrp docker
-user@localhost:~ $ docker run hello-world
-~~~~
diff --git a/docs/2020.4.1/interfaces.md b/docs/2020.4.1/interfaces.md
deleted file mode 100644
index 8dc02afc32f489b6d5eda13d11e8c3de75875ddc..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/interfaces.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# Interfaces
-
-For controlling Cryton there is currently one **CLI** - Command line interface - which uses **REST API** residing in Cryton Core. Via this CLI it is possible to create, execute and control all parts of Attack scenario execution.
-
-As an output interface there is also **Logging** mechanism which logs the most important results and actions to *syslog*.
-
-## REST API
-
-Cryton REST API serves as an (optionally) authenticated endpoint which can be used by other applications.
-
-### Running manually
-
-```
-(cryton-core) root@kali:/opt/cryton# cryton-manage runserver
-Watching for file changes with StatReloader
-Performing system checks...
-
-System check identified no issues (0 silenced).
-Django version 2.2.3, using settings 'cryton.settings'
-Starting development server at http://127.0.0.1:8000/
-Quit the server with CONTROL-C.
-
-```
-
-### Endpoints
-
-You can find swagger generated documentation of endpoints in [swagger](swagger) or the actual swagger documentation when running Cryton REST API. Just browse to ```/doc``` endpoint.
-
-Please note that all returned parameters containing **time** are **UTC** localized.
-
-## CLI
-
-There is also Command line interface available.
\ No newline at end of file
diff --git a/docs/2020.4.1/lifecycle.md b/docs/2020.4.1/lifecycle.md
deleted file mode 100644
index 2735886cf5111f76564ec7d6685893870be99a9f..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/lifecycle.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# Lifecycle
-
-The lifecycle of Attack scenario in Cryton context can be seen in following picture:
-
-
-
-
-
-There are multiple stages which need to be followed for creating and executing the scenario, namely:
-
-* Designing an attack **Template**
-* Creating an **Instance**
-* Scheduling (or directly Executing) a **Run**
-* Generating a **Report**
-
-## Template
-The most important part is creating a Template. This is basically a Plan object written in YAML format. You can find a detailed description of this format in section [Plan](#plan).
-
-Template itself is not a fully described Attack scenario. The structure of the Attack (the execution tree) is correct, but there are still unfilled places, eg. IP addresses of targets or some module arguments. This way an Attack Template can be designed before knowing these details and used in multiple different environments.
-
-The first step in designing of a Plan (attack scenario) is creating a Template. In this step the user is supposed to write the whole scenario in the form of Plan, Stages and Steps. An abstract Plan can look like this:
-
-```
-Plan
- Stage 1
- Step 1
- Step 2
- Stage 2
- Step 3
-```
-
-The format used is a combination of YAML and Jinja. The valid Plan file is written in YAML with variables in the Jinja format, which can be replaced during the instantiation process.
-
-You can use it as in following example:
-
-```
- # Stage two: target is web server
- - name: {{names.stage1}}
-```
-
-You can use Jinja variables everywhere in the Plan template.
-
-## Instance
-The second stage is creating a Instance. While Template contains unfilled variables (therefore the name "template"), Instance fills these things in by combining the Template with an **Inventory file**. This file contains all information that needs to be filled in the Template. After instantiation everything is ready to create a **Run**.
-
-**NOTE: After creating Plan instance only the Step arguments Jinja variables can be left unfilled.**
-
-### Inventory file
-Inventory file is a way of providing variable values to be substituted in the Template file. An example of Inventory file:
-
-```
-[names]
-stage1: 192.168.56.102
-```
-
-## Run
-When you finally have an Instance stored in database, you can create a new Run. For every Worker a new PlanExecution is created.
-The reason behind this is storage of execution history, so it is possible to compare results in Run and usage of different variables for PlanExecutions.
-As mentioned before, you can leave Step argument as an empty Jinja variable. Now, before execution, you can use different values for each PlanExecution.
\ No newline at end of file
diff --git a/docs/2020.4.1/logging.md b/docs/2020.4.1/logging.md
deleted file mode 100644
index 8b2a463d1eb47464e4ea2b8dd08b433225de6dfb..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/logging.md
+++ /dev/null
@@ -1,59 +0,0 @@
-## Logging
-
-Cryton core allows logging into syslog. The logs adhere to following format:
-
-~~~~bash
-Aug 19 04:01:51 kali {"state_from": "PENDING", "state_to": "RUNNING", "stage_id": 1, "stage_name": "ssh-server", "worker": "127.0.0.1:50666", "logger": "Cryton", "level": "info", "timestamp": "2019-08-19T08:01:51.139399Z"}
-Aug 19 04:01:51 kali {"state_from": "PENDING", "state_to": "SCHEDULED", "plan_id": 1, "plan_name": "Example scenario", "worker": "127.0.0.1:50666", "logger": "Cryton", "level": "info", "timestamp": "2019-08-19T08:01:51.151661Z"}
-Aug 19 04:01:51 kali {"state_from": "PENDING", "state_to": "RUNNING", "step_id": 1, "step_name": "scan-victim-ssh", "worker": "127.0.0.1:50666", "result": "NONE", "logger": "Cryton", "level": "info", "timestamp": "2019-08-19T08:01:51.166442Z"}
-Aug 19 04:01:51 kali {"state_from": "RUNNING", "state_to": "FINISHED", "step_id": 1, "step_name": "scan-victim-ssh", "worker": "127.0.0.1:50666", "result": "EXCEPTION", "logger": "Cryton", "level": "info", "timestamp": "2019-08-19T08:01:51.209416Z"}
-Aug 19 04:01:51 kali {"state_from": "PENDING", "state_to": "SKIPPED", "step_id": 2, "step_name": "access-to-ssh", "worker": "127.0.0.1:50666", "result": "NONE", "logger": "Cryton", "level": "info", "timestamp": "2019-08-19T08:01:51.226752Z"}
-Aug 19 04:01:51 kali {"state_from": "PENDING", "state_to": "SKIPPED", "step_id": 3, "step_name": "access-to-ssh-alt", "worker": "127.0.0.1:50666", "result": "NONE", "logger": "Cryton", "level": "info", "timestamp": "2019-08-19T08:01:51.237738Z"}
-Aug 19 04:01:51 kali {"state_from": "PENDING", "state_to": "SKIPPED", "step_id": 4, "step_name": "get-etc-passwd", "worker": "127.0.0.1:50666", "result": "NONE", "logger": "Cryton", "level": "info", "timestamp": "2019-08-19T08:01:51.246326Z"}
-Aug 19 04:01:51 kali {"state_from": "RUNNING", "state_to": "FINISHED", "stage_id": 1, "stage_name": "ssh-server", "worker": "127.0.0.1:50666", "logger": "Cryton", "level": "info", "timestamp": "2019-08-19T08:01:51.259280Z"}
-Aug 19 04:02:51 kali {"state_from": "SCHEDULED", "state_to": "RUNNING", "plan_id": 1, "plan_name": "Example scenario", "worker": "127.0.0.1:50666", "logger": "Cryton", "level": "info", "timestamp": "2019-08-19T08:02:51.015108Z"}
-Aug 19 04:02:51 kali {"state_from": "PENDING", "state_to": "RUNNING", "stage_id": 2, "stage_name": "web-server", "worker": "127.0.0.1:50666", "logger": "Cryton", "level": "info", "timestamp": "2019-08-19T08:02:51.024862Z"}
-Aug 19 04:02:51 kali {"state_from": "PENDING", "state_to": "RUNNING", "step_id": 5, "step_name": "scan-victim-webs", "worker": "127.0.0.1:50666", "result": "NONE", "logger": "Cryton", "level": "info", "timestamp": "2019-08-19T08:02:51.054902Z"}
-Aug 19 04:03:05 kali {"state_from": "RUNNING", "state_to": "FINISHED", "step_id": 5, "step_name": "scan-victim-webs", "worker": "127.0.0.1:50666", "result": "EXCEPTION", "logger": "Cryton", "level": "info", "timestamp": "2019-08-19T08:03:05.946011Z"}
-~~~~
-
-Every Plan/Stage/Step change of state is logged for later analysis. For every Step the result is also stored, although std_out and std_err are (currently) not. They can be found in the database.
-
-The logging configuration can be found in /etc/cryton/logging_config.yaml:
-
-~~~~YAML
----
-version: 1
-disable_existing_loggers: False
-formatters:
- simple:
- format: "%(message)s"
-
-handlers:
- console:
- class: logging.StreamHandler
- level: DEBUG
- formatter: simple
- stream: ext://sys.stdout
-
- sys-logger:
- class: logging.handlers.SysLogHandler
- level: DEBUG
- address: '/dev/log'
- formatter: simple
-
-loggers:
- Cryton:
- level: INFO
- handlers: [sys-logger]
- propagate: yes
-
- Cryton-debug:
- level: DEBUG
- handlers: [console, sys-logger]
- propagate: yes
-...
-~~~~
-
-
-#
\ No newline at end of file
diff --git a/docs/2020.4.1/modules/mod_hydra.md b/docs/2020.4.1/modules/mod_hydra.md
deleted file mode 100644
index 00bf8edd2c059294280067cc7ac2edd2652edc03..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/modules/mod_hydra.md
+++ /dev/null
@@ -1,64 +0,0 @@
-# mod_hydra
-
-This module implemets attacking capabilities of THC hydra bruteforce tool.
-
-## System requirements
-
-System requirements (those not listed in requirements.txt for python).
-
-For this module to function properly, [THC hydra](https://github.com/vanhauser-thc/thc-hydra) needs to be installed.
-
-## Input parameters
-
-Description of input parameters for module.
-
-| Parameter name | Parameter description |
-| --------------- | ------------------------------------------------------------ |
-| `target` | Bruteforce target (must be set when not using command) |
-| `service` | Specified service you want to use to attack (default ssh) |
-| `report_path` | Absolute path where you want to save login pairs - default is Cryton evidence folder |
-| `username` | Username to use for bruteforce |
-| `password` | Password to use for bruteforce |
-| `username_list` | Absolute path to file with usernames |
-| `password_list` | Absolute path to file with passwords |
-| `tasks` | Total number of login pairs to be tested concurrently, default is 16 |
-| `command` | Hydra arguments with syntax as in command line. Do not write 'hydra' into the command. If you specify '-o' parameter with 'cryton_default' it will save file with passwrods to Cryton's default directory and if you specify target parameter ([service://target](service://target)) with 'cryton_default' Cryton's stage target will be used (optional). **Cannot be combined with other input parameters!** |
-
-#### Default command
-
-```bash
--l admin -P /usr/share/wordlists/rockyou.txt -o [cryton_evidence_directory] -t 64 ssh://192.168.1.123
-```
-
-What does it do? It tries to login with credentials [admin - passwords from file] onto ssh on 192.168.1.123 with 64 parallel connections and saves found login pairs into cryton evidence directory (which is automatically generated).
-
-The default command works only on Kali (because of the password list). So if you want to use different password list, or only one password, you can use parameter: 'password' / 'password_list'. It works the same way for any other default parameter.
-
-#### Example yaml(s)
-
-```yaml
-attack_module_args:
- target: 1.2.3.4
- username: admin
- password: pass
-```
-
-## Output
-
-Description of output.
-
-| Parameter name | Parameter description |
-| -------------- | ------------------------------------------------------------ |
-| `username` | Username found during bruteforce |
-| `password` | Password found during bruteforce |
-| `credentials` | If there are more than one login credentials found, they are returned in form of user:password pairs |
-
-#### Example
-
-```json
-{"mod_out": {"credentials": {"admin": "admin", "root": "toor"}}}
-```
-
-```json
-{"mod_out": {"username": "admin", "password": "admin"}}
-```
\ No newline at end of file
diff --git a/docs/2020.4.1/modules/mod_medusa.md b/docs/2020.4.1/modules/mod_medusa.md
deleted file mode 100644
index 523bf2d67ca47f5b9ad7184f558e097679cae510..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/modules/mod_medusa.md
+++ /dev/null
@@ -1,72 +0,0 @@
-# mod_medusa
-
-This module implemets attacking capabilities of Medusa bruteforce tool.
-
-## Requirements
-
-System requirements (those not listed in requirements.txt for python).
-
-For this module to function properly, [Medusa](https://github.com/jmk-foofus/medusa) need to be installed.
-
-## Input parameters
-
-Description of input parameters for module.
-
-| Parameter name | Parameter description |
-| --------------- | ------------------------------------------------------------ |
-| `target` | Bruteforce target (must be set when not using command) |
-| `open_ports` | Parameter for output of module mod_nmap (see [plan example](https://cryton.gitlab-pages.ics.muni.cz/cryton-project/1.0/plan/)) |
-| `mod` | Specified mod(service) you want to use to attack (default ssh) |
-| `report_path` | Absolute path where you want to save login pairs - default is Cryton evidence folder |
-| `username` | Username to use for bruteforce |
-| `password` | Password to use for bruteforce |
-| `username_list` | Absolute path to file with usernames |
-| `password_list` | Absolute path to file with passwords |
-| `combo_list` | Absolute path to file with login pairs - user:password (official format can be found in http://foofus.net/goons/jmk/medusa/medusa.html) |
-| `tasks` | Total number of login pairs to be tested concurrently, default is 16 |
-| `command` | Medusa arguments with syntax as in command line. Do not write 'medusa' into the command. If you specify '-O' parameter with 'cryton_default' it will save file with passwrods to Cryton's default directory **(if you choose other location, do not specify file name)** and if you specify target parameter (-h) with 'cryton_default' Cryton's stage target will be used (optional). **Cannot be combined with other input parameters!** |
-
-#### Default command
-
-```bash
--u admin -P /usr/share/wordlists/rockyou.txt -O [cryton_evidence_directory] -t 16 -h target -M ssh
-```
-
-What does it do? It tries to login with credentials [admin - passwords from file] onto ssh on target with 16 login pair tries concurrently and saves found login pairs into cryton evidence directory (which is automatically generated).
-
-The default command works only on Kali (because of the password list). So if you want to use different password list, or only one password, you can use parameter: 'password' / 'password_list'. It works the same way for any other default parameter.
-
-#### Example yaml(s)
-
-```yaml
-attack_module_args:
- target: 1.2.3.4
- username: admin
- password: pass
- tasks: 64
-```
-
-```yaml
-attack_module_args:
- command: -t 16 -u vagrant -p vagrant -O cryton_default -h 127.0.0.1 -M ssh
-```
-
-## Output
-
-Description of output.
-
-| Parameter name | Parameter description |
-| -------------- | ------------------------------------------------------------ |
-| `username` | Username found during bruteforce |
-| `password` | Password found during bruteforce |
-| `credentials` | If there are more than one login credentials found, they are returned in form of user:password pairs |
-
-#### Example
-
-```json
-{"mod_out": {"credentials": {"admin": "admin", "root": "toor"}}}
-```
-
-```json
-{"mod_out": {"username": "admin", "password": "admin"}}
-```
\ No newline at end of file
diff --git a/docs/2020.4.1/modules/mod_msf.md b/docs/2020.4.1/modules/mod_msf.md
deleted file mode 100644
index 7732e8ffe72eed88a6b8b25d48bceceabcea012e..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/modules/mod_msf.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# mod_msf
-
-Module for orchestrating Metasploit Framework.
-
-## Requirements
-
-System requirements (those not listed in requirements.txt for python).
-
-For this module to function properly, [Metasploit-framework](https://github.com/rapid7/metasploit-framework/wiki/Nightly-Installers) needs to be installed.
-
-After a successful installation of Metasploit-framework, you need to load msgrpc plugin. Easiest way to do this to open your terminal and run `msfrpcd` with `-P toor` to use password and `-S` to turn off SSL (depending on configuration in Worker config file).
-
-**Optional:**
-
-Another option is to run Metasploit using `msfconsole` and load msgrpc plugin using this command:
-
-````bash
-load msgrpc ServerHost=127.0.0.1 ServerPort=55553 User=msf Pass='toor' SSL=true
-````
-
-This is just default, feel free to change the parameters to suit your needs, but keep in mind that they must match your worker config file.
-
-After successfully loading the msgrpc plugin, you are all set and ready to use this module.
-
-## Input parameters
-
-Description of input parameters for module.
-
-| Parameter name | Parameter description |
-| ------------------- | ------------------------------------------------------------ |
-| `exploit` | Exploit present in Metasploit library to be used |
-| `exploit_arguments` | Custom list of Metasploit specific arguments (eg. RHOSTS, RPORT) |
-
-As a default value for RHOSTS, Stage "target" is used.
-
-This module can create sessions using our [Cryton session management](https://cryton.gitlab-pages.ics.muni.cz/cryton-project/1.0/scenario/#session-management) feature.
-
-#### Example yaml(s)
-
-```yaml
-attack_module_args:
- exploit: auxiliary/scanner/ssh/ssh_login
- exploit_arguments:
- RHOSTS: 127.0.0.1
- USERPASS_FILE: /usr/share/metasploit-framework/data/wordlists/root_userpass.txt
-```
-
-## Output
\ No newline at end of file
diff --git a/docs/2020.4.1/modules/mod_nmap.md b/docs/2020.4.1/modules/mod_nmap.md
deleted file mode 100644
index afb5faf2c9cbb7773abc0c80d4f4cc49d612eec4..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/modules/mod_nmap.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# mod_nmap
-
-This module implemets scanning capabilities of Nmap.
-
-It is scanning target's ports. By default it scans the most common ports, returns OK and a list with all ports and their parameters.
-
-With set 'ports' the module is scanning target's ports from the 'ports' list. If those ports match their parameters in port_parameters (default parameter is "state": "open") the module returns OK and a list with all ports and their parameters.
-
-## Requirements
-
-List of system requirements (those not listed in requirements.txt for python).
-
-For this module to function properly, [Nmap](https://github.com/nmap/nmap) need to be installed.
-
-## Input parameters
-
-Description of input parameters for module.
-
-| Parameter name | Parameter description |
-| ---------------------------- | ------------------------------------------------------------ |
-| `target` | Scan target |
-| `ports` | List of ports to be scanned (default scans most common ports) |
-| `port_parameters` (optional) | Check if found ports match your desired parameters. The desired port must be added into 'ports'). Options with examples: {```"host": "1.1.1.1", "hostname": "host", "hostname_type": "", "protocol": "tcp", "port": 22, "name": "ssh", "state": "open", "product": "OpenSSH", "extrainfo": "Ubuntu Linux; protocol 2.0", "reason": "syn-ack", "version": "5.9p1 Debian 5ubuntu1.10", "conf": "10", "cpe": "cpe:/o:linux:linux_kernel"```}. |
-| `command` | Input your own command like in Nmap cli. Do not add 'nmap' into the command. Also do not specify target, Cryton's stage target will be used by default. |
-
-#### Example yaml(s)
-
-```yaml
-attack_module_args:
- target: 127.0.0.1
- ports:
- - 22
-```
-
-```yaml
-attack_module_args:
- target: 127.0.0.1
- ports:
- - 22
- port_parameters: [{"port": 22, "name": "ssh", "product": "OpenSSH"}]
-```
-
-```yaml
-attack_module_args:
- command: -p 22 -sV -T4
-```
-
-## Output
-
-Description of output.
-
-| Parameter name | Parameter description |
-| ---------------- | ------------------------------------------------ |
-| ```open_ports``` | Key:value pairs of open services and their ports |
-
-#### Example
-
-```json
-{"mod_out": {"open_ports": {"ssh": "22", "ftp": "21"}}}
-```
\ No newline at end of file
diff --git a/docs/2020.4.1/modules/mod_test.md b/docs/2020.4.1/modules/mod_test.md
deleted file mode 100644
index 045c8b7e8121198610cb46eaedae64da870f2d2d..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/modules/mod_test.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# mod_test
-
-Description - template for writing attack modules documentation
-
-## Requirements
-list of system requirements (those not listed in requirements.txt for python)
-
-```apt install vim nc```
-
-## Input parameters
-
-Description of input parameters for module.
-
-| Parameter name | Parameter description |
-| -------------- | --------------------- |
-| ```username``` | Username to use |
-| ```password``` | Password to use |
-
-## Output
-
-Description of output
-
-| Parameter name | Parameter description |
-| ---------------- | --------------------- |
-| ```session_id``` | Metasploit session id |
-
-#### Example
-```{'session_id': 42}```
\ No newline at end of file
diff --git a/docs/2020.4.1/plan-execution.md b/docs/2020.4.1/plan-execution.md
deleted file mode 100644
index 69eb111c21951de40bbded64417fe12d3e5a9c38..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/plan-execution.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Plan execution
-
-For every execution of Plan (on a given Worker) a new PlanExecution is created. This execution contains:
-
-* Start time of execution
-* Finish time of execution
-* last Pause time of execution (if available)
-* State of execution
-* Worker on which it is running
-* Run of which it is a part of
-
-Importance of this object is in keeping the history of executions of a given run. This object also connects all other sub-executions (for Stage and Step) in a one logical unit - Run.
\ No newline at end of file
diff --git a/docs/2020.4.1/session-mngmt.md b/docs/2020.4.1/session-mngmt.md
deleted file mode 100644
index 10f2dcca400fabfacbe9d4eeec7b512eb6558261..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/session-mngmt.md
+++ /dev/null
@@ -1,19 +0,0 @@
-### Session management
-
-One of the unique features of Cryton is ability to create and use *sessions* - connections to the target systems.
-When you successfully exploit a running network service on your target machine (victim), you open a connection to it.
-In Cryton, this connection can be given name and then used during the Plan execution in any Step (which is executed on the same Worker node).
-Metasploit Framework session management is used for storing and interacting with sessions, and therefore must be available and running on the Worker node.
-
-```yaml
-- name: step1
- attack_module: ...
- create_named_session: session_to_target_1
-- name: step2
- attack_module: ...
- use_named_session: session_to_target_1
-```
-
-In the example above, step1 creates a named session *session_to_target_1* (in case it succeeds).
-It's Metasploit ID gets stored in database and can be used anywhere in the Plan, not only in following Step (as seen in example).
-When the Plan creates multiple sessions to the same target, and the attacker does not care which he is using, *use_any_session_to_target* parameter can be used.
\ No newline at end of file
diff --git a/docs/2020.4.1/stage-execution.md b/docs/2020.4.1/stage-execution.md
deleted file mode 100644
index e4a40e6a089b0fc6587593d654107b2cd8210077..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/stage-execution.md
+++ /dev/null
@@ -1,10 +0,0 @@
-# Stage execution
-
-For every execution of Stage a new StageExecution is created. This execution contains:
-
-* Start time of execution
-* Finish time of execution
-* last Pause time of execution (if available)
-* State of execution
-* PlanExecution of which it is a part of
-
diff --git a/docs/2020.4.1/stage.md b/docs/2020.4.1/stage.md
deleted file mode 100644
index 657313c96265712425f47ab5081aa791476536bb..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/stage.md
+++ /dev/null
@@ -1,37 +0,0 @@
-
-Stage is a unit defined by a target and a time of start. It contains a list of attack Steps.
-
-### Triggering
-
-#### trigger_type
-
-A type of trigger to be used. Available triggers are:
-
-| Type | Meaning |
-| -------------- | ------------------------------------------------------------ |
-| `delta` | Schedule execution for specific time after plan start, eg. `minutes: 30` |
-| `HTTPListener` | (Currently in development) Stage will be executed on specific data received on the listener |
-
-#### trigger_args
-
-Trigger arguments, that are specific for every type of trigger.
-
-### Example
-
-```yaml
-- name: stage-one
- trigger_type: delta
- trigger_args:
- minutes: 5
- steps:
- - name: scan-localhost
- is_init: true
- attack_module: infrastructure/scan/mod_nmap
- attack_module_args:
- ports:
- - 22
- next:
- - type: result
- value: OK
- step: ssh-bruteforce
-```
diff --git a/docs/2020.4.1/step-execution.md b/docs/2020.4.1/step-execution.md
deleted file mode 100644
index b9e391b061b91b12a5e91d5dbde6c73478a4f4c0..0000000000000000000000000000000000000000
--- a/docs/2020.4.1/step-execution.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# Step execution
-
-For every execution of Step a new StepExecution is created. This execution contains:
-
-* Start time of execution
-* Finish time of execution
-* last Pause time of execution (if available)
-* State of execution
-* StageExecution of which it is a part of
-
-In addition, results of Attack module execution are stored in this object:
-
-* mod_out
-* mod_err
-* std_out
-* std_err
-* result
-* evidence_file
-
diff --git a/docs/2021.2.1/advanced-example.md b/docs/2021.2.1/advanced-example.md
new file mode 100644
index 0000000000000000000000000000000000000000..d2655d7968bd50a7afd16c418df850f948842c32
--- /dev/null
+++ b/docs/2021.2.1/advanced-example.md
@@ -0,0 +1,240 @@
+## Set up Workers
+
+With workers installed via this [tutorial](install-worker.md), you can set them up in [cryton-cli](cli.md). In this tutorial, it's assumed that cryton-core and cryton-cli is installed on the same machine. If not use `cryton-cli -H 127.0.0.1 -p 8000 --secure ...` to connect cryton-cli to cryton-core.
+
+```shell
+cryton-cli workers create worker_ip_address name -p customPrefix
+```
+
+**example**:
+
+```shell
+cryton-cli workers create localhost worker1 -p test1
+Worker successfully created! ({'worker_model_id': 1, 'link': 'http://127.0.0.1:8000/cryton/api/v1/workers/1/'})
+```
+
+```shell
+cryton-cli workers create localhost worker2 -p test2
+Worker successfully created! ({'worker_model_id': 2, 'link': 'http://127.0.0.1:8000/cryton/api/v1/workers/2/'}).
+```
+
+**Note:** If using multiple workers, they should not be on the same machine for the [example plan](#Plan-template-example) below to work because of the [HTTPListener](stage.md##Triggering) listening on a specific port.
+
+## Create a Template
+
+Create [plan template](template.md) using a file containing the desired plan YAML:
+
+```shell
+cryton-cli plan-templates create path/to/example
+```
+
+**example**:
+
+```shell
+cryton-cli plan-templates create cryton-core/examples/plans/advanced-example.yaml
+Template successfully created! ({'url': 'http://127.0.0.1:8000/cryton/api/v1/templates/1/', 'id': 1, 'file': 'http://127.0.0.1:8000/uploads/execution-variables-example_YmlZuKl.yaml'}).
+```
+
+### Plan template example
+
+To trigger `stage-two`, GET request with parameters and defined in HTTPListener under `routes` needs to be send to host:port defined under `trigger_args`. So in this example, GET request from terminal should look like `curl http://localhost:8082/index?a=1`.
+
+```yaml
+---
+plan:
+ name: Advanced example
+ owner: test name
+ stages:
+ - name: stage-one
+ trigger_type: delta
+ trigger_args:
+ seconds: 5
+ steps:
+ - name: scan-localhost
+ is_init: true
+ attack_module: mod_nmap
+ attack_module_args:
+ target: "{{ target }}" # execution variable
+ ports:
+ - 22
+ next:
+ - type: result
+ value: OK
+ step: bruteforce
+ - name: bruteforce
+ attack_module: mod_medusa
+ attack_module_args:
+ target: "{{ target }}" # execution variable
+ credentials:
+ username: "{{ username }}" # execution variable
+ # default password_list will be used for bruteforce
+ - name: stage-two
+ depends_on:
+ - stage-one
+ trigger_type: HTTPListener
+ trigger_args:
+ host: localhost
+ port: 8082
+ routes:
+ - path: /index
+ method: GET
+ parameters:
+ - name: a
+ value: "1"
+ steps:
+ - name: ssh-session
+ is_init: true
+ attack_module: mod_msf
+ attack_module_args:
+ create_named_session: session_to_target_1
+ exploit: auxiliary/scanner/ssh/ssh_login
+ exploit_arguments:
+ RHOSTS: "{{ target }}" # execution variable
+ USERNAME: $bruteforce.username
+ PASSWORD: $bruteforce.password
+ next:
+ - type: result
+ value: OK
+ step: session-cmd
+ - name: session-cmd
+ attack_module: mod_cmd
+ attack_module_args:
+ use_named_session: session_to_target_1
+ cmd: {{ commands.passwd }} # inventory file variable
+```
+
+#### Featured functionalities
+
+This example plan features cryton functionalities such as [triggers](stage.md#Triggering), [execution variables](step.md#Execution-variables), [inventory files](instance.md#Inventory-files), [output sharing](step.md#Output-sharing), [session management](session-mngmt.md).
+
+#### Used modules
+
+Modules used in this example are [mod_nmap](modules/mod_nmap.md), [mod_medusa](modules/mod_medusa.md), [mod_msf](modules/mod_msf.md), [mod_cmd](modules/mod_cmd.md).
+
+## Create an Instance
+
+Create [Instance](instance.md) from created [plan template](template.md) and [inventory file](instance.md#Inventory-files).
+
+```shell
+cryton-cli plans create 1 -i inventory_file1
+Plan Instance successfully created! ({'plan_model_id': 1, 'link': 'http://127.0.0.1:8000/cryton/api/v1/plans/1/'}).
+```
+
+### Inventory file example
+
+```ini
+[commands]
+passwd: cat /etc/passwd
+```
+
+**Note:** Inventory files are not required, this is just functionality demonstration.
+
+## Create a Run
+
+Create [run](run.md) from previously created [instance](instance.md) and workers. First is plan_id and then id of workers.
+
+```shell
+cryton-cli runs create 1 1 2
+Run successfully created! ({'run_model_id': 1, 'link': 'http://127.0.0.1:8000/cryton/api/v1/runs/1/'}).
+```
+
+### Add Execution variables
+
+Now there should be created 2 [plan-executions](execution.md#Plan-execution), one for each worker. You can view them with:
+
+```shell
+cryton-cli plan-executions list
+id: 1, schedule_time: None, start_time: None, pause_time: None, finish_time: None, state: PENDING, evidence_dir: None, worker: http://127.0.0.1:8000/cryton/api/v1/workers/1/
+
+
+id: 2, schedule_time: None, start_time: None, pause_time: None, finish_time: None, state: PENDING, evidence_dir: None, worker: http://127.0.0.1:8000/cryton/api/v1/workers/2/
+```
+
+[Inventory file](instance.md) needs to be created for each [instance](instance.md). For plan example above, inventory files could look like this.
+
+**Execution variables file for Plan-execution 1:**
+
+```ini
+target: 127.0.0.1
+username: vagrant
+```
+
+**Execution variables file for Plan-execution 2:**
+
+```ini
+target: 127.0.0.1
+username: admin
+```
+
+Add created [execution variables](step.md#Execution-variables) to the [plan-executions](execution.md#Plan-execution) that you want to execute them with.
+
+```shell
+cryton-cli execution-variables create 1 exec_variables1.txt
+Execution variable(s) successfully created! ([1, 2, 3]).
+```
+
+```shell
+cryton-cli execution-variables create 2 exec_variables2.txt
+Execution variable(s) successfully created! ([4, 5, 6]).
+```
+
+**Note:** Execution variables are not required, this is just functionality demonstration.
+
+## Schedule or Execute
+
+#### Schedule run
+
+Run executions can be scheduled to a specific date/time using local timezone.
+
+```shell
+cryton-cli runs schedule 1 2020-06-08 10:00:00
+Run successfully scheduled! (Run 1 is scheduled for 2020-06-08 10:00:00.).
+```
+
+#### Execute run
+
+```shell
+cryton-cli runs execute 1
+Run successfully executed! (Run 1 was executed.).
+```
+
+### Pause/Unpause
+
+Runs in progress can be paused with run_id:
+
+```shell
+cryton-cli runs pause 1
+```
+
+And then resumed using:
+
+```shell
+cryton-cli runs resume 1
+```
+
+## Report results
+
+#### List runs
+
+To see if executed runs are finished, you can list runs and look at its **state**:
+
+```shell
+cryton-cli runs list
+id: 1, schedule_time: None, start_time: 2021-05-24T00:08:45.200025, pause_time: None, finish_time: 2021-05-24T00:09:18.397199, state: FINISHED, plan_model: http://127.0.0.1:8000/cryton/api/v1/plans/1/
+```
+
+#### View report
+
+Reports can be viewed directly in cryton-cli:
+
+`cryton-cli runs report 1 --less`
+
+#### Generate report
+
+or they can be saved to a /tmp/ directory:
+
+```shell
+cryton-cli runs report 1
+Successfully created Run's report! (file saved at: /tmp/report_run_1_2020-06-08-10-15-00-257994_xdQeV)
+```
+
diff --git a/docs/2020.4.1/architecture.md b/docs/2021.2.1/architecture.md
similarity index 73%
rename from docs/2020.4.1/architecture.md
rename to docs/2021.2.1/architecture.md
index c2469475962a48e6c023e3e5c01acc41cee3bad5..ab7022b176c38b481f40d52fa93dc06d78398fbf 100644
--- a/docs/2020.4.1/architecture.md
+++ b/docs/2021.2.1/architecture.md
@@ -4,7 +4,7 @@
## Core
-As the name suggests, this is the **Core** component of Cryton toolset. It provides all the functionality for parsing the Attack Plans, creation of Executions and scheduling of Runs. Scheduling itself is done via **Scheduler** component, which shares **Database** with Core.
+As the name suggests, this is the **Core** component of Cryton toolset. It provides all the functionality for parsing the Attack Plans, creation of Executions and scheduling of Runs.
For issuing commands to Core, **REST API** is provided. This is utilized by **CLI** for normal user interactions.
@@ -15,7 +15,3 @@ Cryton worker is a component for executing Cryton attack modules remotely. Cryto
## Modules
Cryton modules component contains attack modules used by Cryton Worker. It's usage is described further in the documentation.
-
-## Scheduler
-
-APScheduler implementation which executes scheduled Runs on specified time. Connection between Core and Scheduler component is via RPYC.
\ No newline at end of file
diff --git a/docs/2020.4.1/attack-modules.md b/docs/2021.2.1/attack-modules.md
similarity index 69%
rename from docs/2020.4.1/attack-modules.md
rename to docs/2021.2.1/attack-modules.md
index 117ffc29f102b7e9d3ed29e03655c16d09e3d86d..43a21929f336e495c7a63179b50a46cc605ce967 100644
--- a/docs/2020.4.1/attack-modules.md
+++ b/docs/2021.2.1/attack-modules.md
@@ -15,12 +15,12 @@ Every attack module returns a dictionary with following keys:
| Parameter name | Parameter meaning |
| -------------- | ------------------------------------------------------------ |
-| `return_code` | Numeric representation of result <br />0 means OK<br />-1 means FAIL<br />-2 means EXCEPTION |
-| `mod_out` | Parsed output of module. Eg. for bruteforcing module, this might be a list of found usernames and passwords. Every mod_out is described in respective module documentation. |
-| `mod_err` | Error message with description of the problem, if identified. If not identified, error message is stored in ```mod_err```. |
+| `return_code` | Numeric representation of result (0, -1, -2) <br />0 (OK) means the module finished successfully<br />-1 (FAIL) means the module finished unsuccessfully<br />-2 (EXCEPTION) means the module finished with an error |
+| `mod_out` | Parsed output of module. Eg. for bruteforce module, this might be a list of found usernames and passwords. |
+| `mod_err` | Error message with description of the problem. |
| `std_out` | Standard output (```std_out```) of any executed command (but mostly None) |
| `std_err` | Standard error (```std_err```) of any executed command (but mostly None) |
-| `file` | A module can also return a file. It is a python dictionary with keys `file_name` and `file_contents`. This file will be stored on Core machine. The local path will be added to return dictionary of Step under the key `evidence_file`. |
+| `file` | A module can also return a file. It has to be a Python dictionary with keys `file_name` and `file_content` (optionally `file_encoding`, which can contain only `"base64"` or `None`). The file will be stored on the machine running Cryton Core. |
diff --git a/docs/2021.2.1/basic-example.md b/docs/2021.2.1/basic-example.md
new file mode 100644
index 0000000000000000000000000000000000000000..8252448bfd335b2bdc8513fd10d83a92d4d1b3f6
--- /dev/null
+++ b/docs/2021.2.1/basic-example.md
@@ -0,0 +1,125 @@
+## Set up Worker
+
+With worker installed via this [tutorial](install-worker.md), you can set them up in [cryton-cli](cli.md). In this tutorial, it's assumed that cryton-core and cryton-cli is installed on the same machine. If not use `cryton-cli -H 127.0.0.1 -p 8000 --secure ...` to connect cryton-cli to cryton-core.
+
+```shell
+cryton-cli workers create worker_ip_address name -p custom_refix
+```
+
+**example**:
+
+```shell
+cryton-cli workers create localhost worker1 -p test1
+Worker successfully created! ({'worker_model_id': 1, 'link': 'http://127.0.0.1:8000/cryton/api/v1/workers/1/'}).
+```
+
+## Create a Template
+
+Create [plan-template](template.md) using a file containing the desired plan YAML:
+
+```shell
+cryton-cli plan-templates create path/to/example
+```
+
+**example**:
+
+```shell
+cryton-cli plan-templates create ../cryton-core/examples/plans/basic-example.yaml
+
+Template successfully created! ({'url': 'http://127.0.0.1:8000/cryton/api/v1/templates/1/', 'id': 1, 'file': 'http://127.0.0.1:8000/uploads/execution-variables-example_YmlZuKl.yaml'}).
+```
+
+### Plan template example
+
+```yaml
+---
+plan:
+ name: Simulation example
+ owner: test name
+ stages:
+ - name: stage-one
+ trigger_type: delta
+ trigger_args:
+ seconds: 5
+ steps:
+ - name: scan-localhost
+ is_init: true
+ attack_module: mod_nmap
+ attack_module_args:
+ target: 127.0.0.1
+ ports:
+ - 22
+ next:
+ - type: result
+ value: OK
+ step: bruteforce
+ - name: bruteforce
+ attack_module: mod_medusa
+ attack_module_args:
+ target: 127.0.0.1
+ credentials:
+ username: vagrant
+ # default password_list will be used for bruteforce
+```
+
+## Create an Instance
+
+Create [Instance](instance.md) from created [plan template](template.md).
+
+```shell
+cryton-cli plans create 1
+Plan Instance successfully created! ({'plan_model_id': 1, 'link': 'http://127.0.0.1:8000/cryton/api/v1/plans/1/'}).
+```
+
+## Create a Run
+
+Create [run](run.md) from previously created [instance](instance.md) and worker. First is plan_id and then id of worker.
+
+```shell
+cryton-cli runs create 1 1
+Run successfully created! ({'run_model_id': 1, 'link': 'http://127.0.0.1:8000/cryton/api/v1/runs/1/'}).
+```
+
+## Schedule or Execute
+
+#### Schedule run
+
+Run executions can be scheduled to a specific date/time using local timezone.
+
+```shell
+cryton-cli runs schedule 1 2020-06-08 10:00:00
+Run successfully scheduled! (Run 1 is scheduled for 2020-06-08 10:00:00.).
+```
+
+#### Execute run
+
+```shell
+cryton-cli runs execute 1
+Run successfully executed! (Run 1 was executed.).
+```
+
+## Report results
+
+#### List runs
+
+To see if executed runs are finished, you can list runs and look at its **state**:
+
+```shell
+cryton-cli runs list
+id: 1, schedule_time: None, start_time: 2021-05-24T00:08:45.200025, pause_time: None, finish_time: 2021-05-24T00:09:18.397199, state: FINISHED, plan_model: http://127.0.0.1:8000/cryton/api/v1/plans/1/
+```
+
+#### View report
+
+Reports can be viewed directly in cryton-cli:
+
+`cryton-cli runs report 1 --less`
+
+#### Generate report
+
+or they can be saved to a /tmp/ directory:
+
+```shell
+cryton-cli runs report 1
+Successfully created Run's report! (file saved at: /tmp/report_run_1_2020-06-08-10-15-00-257994_xdQeV)
+```
diff --git a/docs/2020.4.1/cli.md b/docs/2021.2.1/cli.md
similarity index 93%
rename from docs/2020.4.1/cli.md
rename to docs/2021.2.1/cli.md
index 7cecf9e46a8be00626454dbe8970bf053bf61360..157a9a6835e20efed938081bb7c2828810fa7011 100644
--- a/docs/2020.4.1/cli.md
+++ b/docs/2021.2.1/cli.md
@@ -1,8 +1,8 @@
-## CLI
+
CLI implements capabilities of Cryton's REST API and can be automated by using custom scripts.
-To start the CLI just type in `cryton-cli`:
+To start the CLI just type `cryton-cli` and the following should show:
```
Usage: cryton-cli [OPTIONS] COMMAND [ARGS]...
@@ -41,7 +41,7 @@ The default Cryton's REST API address and port are **localhost** and **8000**. T
Optionally use `--secure` flag to use *HTTPS* protocol or `--debug` flag for non formatted output.
```
-(cryton-cli) root@localhost:~/cryton-cli$ cryton-cli -H 127.0.0.1 -p 8000 --secure ...
+cryton-cli -H 127.0.0.1 -p 8000 --secure ...
```
To show help at any point use `--help` option. For example: `cryton-cli plans list --help`.
@@ -53,7 +53,7 @@ Manage Execution variables from here.
`create` Create new execution variable(s) for PlAN_EXECUTION_ID from FILE.
Example: `cryton-cli execution-variables create 1 /path/to/file`
-- argument `PlAN_EXECUTION_ID` - ID of the desired PlanExecution.
+- argument `PLAN_EXECUTION_ID` - ID of the desired PlanExecution.
- argument `FILE` - Path to file containing execution variables.
`delete` Delete Execution variable with EXECUTION_VARIABLE_ID saved in Cryton.
@@ -193,6 +193,10 @@ Example: `cryton-cli runs unschedule 1`
- argument `RUN_ID` - ID of the Run you want to unschedule.
+`kill` Kill Run saved in Cryton with RUN_ID.
+Example: `cryton-cli runs kill 1`
+
+- argument `RUN_ID` - ID of the Run you want to kill.
### plan-executions
@@ -205,6 +209,7 @@ Example: `cryton-cli plan-executions list`
- option `--offset` - The initial index from which to return the results.
- option `--limit` - Number of results to return per page.
- option `--localize` - Convert UTC datetime to local timezone.
+- option `--parent` - Filter Plan-executions using Run ID.
`report` Create report for Plan's execution with EXECUTION_ID saved in Cryton.
Example: `cryton-cli plan-executions report 1 -f /path/to/directory`
@@ -235,6 +240,11 @@ Example: `cryton-cli plan-executions validate-modules 1`
- argument `EXECUTION_ID` - ID of the Plan's execution you want to validate modules for.
+`kill` Kill Plan's execution with EXECUTION_ID saved in Cryton.
+Example: `cryton-cli plan-executions kill 1`
+
+- argument `EXECUTION_ID` - ID of the Plan's execution you want to kill.
+
### plans
Manage Plans from here.
@@ -289,6 +299,7 @@ Example: `cryton-cli stage-executions list`
- option `--offset` - The initial index from which to return the results.
- option `--limit` - Number of results to return per page.
- option `--localize` - Convert UTC datetime to local timezone.
+- option `--parent` - Filter Stage-executions using Plan-execution ID.
`report` Create report for Stage's execution with EXECUTION_ID saved in Cryton.
Example: `cryton-cli stage-executions report 1 -f /path/to/directory`
@@ -304,6 +315,11 @@ Example: `cryton-cli stage-executions show 1`
- option `--less` - Show less like output.
- option `--localize` - Convert UTC datetime to local timezone.
+`kill` Kill Stage's execution with EXECUTION_ID saved in Cryton.
+Example: `cryton-cli stage-executions kill 1`
+
+- argument `EXECUTION_ID` - ID of the Stage's execution you want to kill.
+
### stages
Manage Stages from here.
@@ -333,6 +349,7 @@ Example: `cryton-cli stages list`
- option `--offset` - The initial index from which to return the results.
- option `--limit` - Number of results to return per page.
- option `--localize` - Convert UTC datetime to local timezone.
+- option `--parent` - Filter Stages using Plan ID.
`show` Show Stage with STAGE_ID saved in Cryton.
Example: `cryton-cli stages show 1`
@@ -358,6 +375,7 @@ Example: `cryton-cli step-executions list`
- option `--offset` - The initial index from which to return the results.
- option `--limit` - Number of results to return per page.
- option `--localize` - Convert UTC datetime to local timezone.
+- option `--parent` - Filter Step-executions using Stage-execution ID.
`report` Create report for Step's execution with EXECUTION_ID saved in Cryton.
Example: `cryton-cli step-executions report 1 -f /path/to/directory`
@@ -373,6 +391,11 @@ Example: `cryton-cli step-executions show 1`
- option `--less` - Show less like output.
- option `--localize` - Convert UTC datetime to local timezone.
+`kill` Kill Step's execution with EXECUTION_ID saved in Cryton.
+Example: `cryton-cli step-executions kill 1`
+
+- argument `EXECUTION_ID` - ID of the Step's execution you want to kill.
+
### steps
Manage Steps from here.
@@ -402,6 +425,7 @@ Example: `cryton-cli steps list`
- option `--offset` - The initial index from which to return the results.
- option `--limit` - Number of results to return per page.
- option `--localize` - Convert UTC datetime to local timezone.
+- option `--parent` - Filter Steps using Stage ID.
`show` Show Step with STEP_ID saved in Cryton.
Example: `cryton-cli steps show 1`
diff --git a/docs/2021.2.1/execution.md b/docs/2021.2.1/execution.md
new file mode 100644
index 0000000000000000000000000000000000000000..ec21383290d8801c63907ed1b6bfec1a94851ddd
--- /dev/null
+++ b/docs/2021.2.1/execution.md
@@ -0,0 +1,58 @@
+# Execution
+
+There are special kinds of objects called *Executions* for every unit in Attack scenario:
+
+* **PlanExecution**
+* **StageExecution**
+* **StepExecution**
+
+These are not objects that need to be created by you - instead they are created when their respective unit is executed. This way a history and results of each and every execution can be stored.
+
+Every Execution object stores a start and finish time, so it is easy to count running times of each unit. With Steps the Execution is also a place where the output and results from attack modules is stored.
+
+
+## Plan execution
+
+For every execution of Plan (on a given Worker) a new PlanExecution is created. This execution contains:
+
+* Start time of execution
+* Finish time of execution
+* last Pause time of execution (if available)
+* State of execution
+* Worker on which it is running
+* Run of which it is a part of
+
+Importance of this object is in keeping the history of executions of a given run. This object also connects all other sub-executions (for Stage and Step) in a one logical unit - Run.
+
+## Stage execution
+
+For every execution of Stage a new StageExecution is created. This execution contains:
+
+* Start time of execution
+* Finish time of execution
+* last Pause time of execution (if available)
+* State of execution
+* PlanExecution of which it is a part of
+
+## Step execution
+
+For every execution of Step a new StepExecution is created. This execution contains:
+
+* Start time of execution
+* Finish time of execution
+* last Pause time of execution (if available)
+* State of execution
+* StageExecution of which it is a part of
+
+In addition, results of Attack module execution are stored in this object:
+
+* mod_out
+* mod_err
+* std_out
+* std_err
+* result
+* evidence_file
+
+
+
+
diff --git a/docs/2021.2.1/howto-create-attack-modules.md b/docs/2021.2.1/howto-create-attack-modules.md
new file mode 100644
index 0000000000000000000000000000000000000000..085cd317c6f4af087b0ced69022dcab0a3894184
--- /dev/null
+++ b/docs/2021.2.1/howto-create-attack-modules.md
@@ -0,0 +1,148 @@
+Each module has its own folder, which will be used in plan templates. The following structure is used when creating modules:
+```
+mod_custom
+├── example.py
+├── mod.py
+├── README.md
+├── requirements.txt
+└── test_mod.py
+```
+**IMPORTANT: Don't use custom file names.**
+
+### mod.py
+_Attack module_ is a module implementing two functions: execute(args) returning a specific return structure (in the form of dict) and validate(args) function returning True or False (depending on valid arguments provided).
+
+```python
+def execute(args):
+ ret_vals = dict()
+ my_argument = args.get('my_argument')
+
+ return ret_vals
+
+def validate(args):
+ if args.get('nonoptional_argument') is not None:
+ return 0
+ else:
+ raise Exception
+
+```
+
+If you want to store an evidence file from a module in the Cryton master's default evidence directory, add the following code into your execute function:
+
+```python
+with open(file_path, 'rb') as bin_file:
+ file_content = bin_file.read()
+
+ret_vals.update({'file': {'file_name': desired_file_name, 'file_content': file_content}})
+```
+
+#### Output (dictionary) parameters
+
+| Parameter name | Parameter meaning |
+| -------------- | ------------------------------------------------------------ |
+| `return_code` | Numeric representation of result (0, -1, -2) <br />0 (OK) means the module finished successfully<br />-1 (FAIL) means the module finished unsuccessfully<br />-2 (EXCEPTION) means the module finished with an error |
+| `mod_out` | Parsed output of module. Eg. for bruteforce module, this might be a list of found usernames and passwords. |
+| `mod_err` | Error message with description of the problem. |
+| `std_out` | Standard output (```std_out```) of any executed command (but mostly None) |
+| `std_err` | Standard error (```std_err```) of any executed command (but mostly None) |
+| `file` | A module can also return a file. It has to be a Python dictionary with keys `file_name` and `file_content` (optionally `file_encoding`, which can contain only `"base64"` or `None`). The file will be stored on the machine running Cryton Core. |
+
+### test_mod.py
+Unit tests for you module.
+```python
+import unittest
+import mod
+
+
+class CustomTest(unittest.TestCase):
+ def test_my_custom_mod(self):
+ ret = mod.execute(self.args)
+ self.assertEqual(ret.get('return_code'), 0)
+```
+
+### example.py
+Example execution for quick start or testing.
+```python
+from mod import execute, validate
+
+args = {
+ "arg1": "127.0.0.1",
+ "arg2": "username",
+ "arg3": "password"
+}
+
+try:
+ val_output = validate(args)
+ print("validate output: "+str(val_output))
+except Exception as ex:
+ print(ex)
+
+try:
+ ex_output = execute(args)
+ print("execute output: "+str(ex_output))
+except Exception as ex:
+ print(ex)
+```
+
+### README.md
+~~~
+# mod_custom
+General information about module.
+
+## Requirements
+System requirements (those not listed in requirements.txt for python).
+
+## Input parameters
+Description of input parameters for module.
+
+| Parameter name | Parameter description |
+| ----------------- | ---------------------- |
+| `arg1` (required) | Parameter 1 |
+| `arg2` (optional) | Parameter 2 |
+
+## Example yaml(s)
+
+``` yaml
+attack_module_args:
+ arg1: content
+ arg2: content
+```
+~~~
+
+
+### Output
+
+Description of output.
+
+| Parameter name | Parameter description |
+| --------------- | ------------------------------------------------------- |
+| `file_content` | File that contains output of command in `cmd` parameter |
+
+#### Example
+
+**With `output_file` parameter:**
+
+```json
+{"mod_out": {"file_content": "path/to/file"}}
+```
+
+**Without `output_file` parameter:**
+
+```json
+{"mod_out": {"cmd_out": "command output"}}
+```
+
+
+### requirements.txt
+
+File containing module's Python requirements.
+```
+python_lib==1.2.3
+```
+
+### Worker prebuilt functionality
+Worker provides prebuilt functionality (limited for now) to make building modules easier. Import it using:
+```python
+from cryton_worker.lib.util import module_util
+```
+For more information check out [Worker](https://gitlab.ics.muni.cz/cryton/cryton-worker) README.md.
\ No newline at end of file
diff --git a/docs/2020.4.1/images/architecture.png b/docs/2021.2.1/images/architecture.png
similarity index 100%
rename from docs/2020.4.1/images/architecture.png
rename to docs/2021.2.1/images/architecture.png
diff --git a/docs/2020.4.1/images/core-component.png b/docs/2021.2.1/images/core-component.png
similarity index 100%
rename from docs/2020.4.1/images/core-component.png
rename to docs/2021.2.1/images/core-component.png
diff --git a/docs/2020.4.1/images/flow-diagram.png b/docs/2021.2.1/images/flow-diagram.png
similarity index 100%
rename from docs/2020.4.1/images/flow-diagram.png
rename to docs/2021.2.1/images/flow-diagram.png
diff --git a/docs/2020.4.1/images/lifecycle.png b/docs/2021.2.1/images/lifecycle.png
similarity index 100%
rename from docs/2020.4.1/images/lifecycle.png
rename to docs/2021.2.1/images/lifecycle.png
diff --git a/docs/2020.4.1/images/micro-cryton.png b/docs/2021.2.1/images/micro-cryton.png
similarity index 100%
rename from docs/2020.4.1/images/micro-cryton.png
rename to docs/2021.2.1/images/micro-cryton.png
diff --git a/docs/2020.4.1/images/modules-component.png b/docs/2021.2.1/images/modules-component.png
similarity index 100%
rename from docs/2020.4.1/images/modules-component.png
rename to docs/2021.2.1/images/modules-component.png
diff --git a/docs/2021.2.1/images/stage.png b/docs/2021.2.1/images/stage.png
new file mode 100644
index 0000000000000000000000000000000000000000..3858a843705abe392ff5a4949a87eae91a8f7fd8
Binary files /dev/null and b/docs/2021.2.1/images/stage.png differ
diff --git a/docs/2021.2.1/images/swagger.png b/docs/2021.2.1/images/swagger.png
new file mode 100644
index 0000000000000000000000000000000000000000..fb257d51caa91bd0c77fa66e37a1761cb45637d6
Binary files /dev/null and b/docs/2021.2.1/images/swagger.png differ
diff --git a/docs/2021.2.1/images/template.png b/docs/2021.2.1/images/template.png
new file mode 100644
index 0000000000000000000000000000000000000000..7883c1df4939c1025f43309bdfa934e0e263fe66
Binary files /dev/null and b/docs/2021.2.1/images/template.png differ
diff --git a/docs/2020.4.1/images/templates.png b/docs/2021.2.1/images/templates.png
similarity index 100%
rename from docs/2020.4.1/images/templates.png
rename to docs/2021.2.1/images/templates.png
diff --git a/docs/2020.4.1/images/worker-component.png b/docs/2021.2.1/images/worker-component.png
similarity index 100%
rename from docs/2020.4.1/images/worker-component.png
rename to docs/2021.2.1/images/worker-component.png
diff --git a/docs/2020.4.1/install-cli.md b/docs/2021.2.1/install-cli.md
similarity index 87%
rename from docs/2020.4.1/install-cli.md
rename to docs/2021.2.1/install-cli.md
index 5e78699a1784fb11a7d47574c1124e203ce2e14e..0b93f68d49e6a2618276beeff3007e7e1a03a7a0 100644
--- a/docs/2020.4.1/install-cli.md
+++ b/docs/2021.2.1/install-cli.md
@@ -2,12 +2,10 @@
For this installation we are assuming installation on the same machine. Please update variables for your use case.
-Cryton CLI uses environment variables for it's settings.
+Cryton CLI uses environment variables for its settings.
~~~~
CRYTON_CLI_TIME_ZONE=AUTO
-CRYTON_CLI_CLI_VERSION=2.0
-CRYTON_CLI_CRYTON_VERSION=2.0
CRYTON_CLI_API_RHOST=127.0.0.1
CRYTON_CLI_API_RPORT=8000
CRYTON_CLI_API_SSL=False
@@ -16,7 +14,7 @@ CRYTON_CLI_API_ROOT_URL=cryton/api/v1/
#### Requirements
-- python3.8 (tested version)
+- python3.8 (tested)
- pipenv (optional)
#### Installation
@@ -24,7 +22,6 @@ CRYTON_CLI_API_ROOT_URL=cryton/api/v1/
Go into Cryton CLI directory, create python environment, enter it and install CLI.
~~~~
-cd cryton-cli
pipenv install
pipenv shell
python setup.py install
diff --git a/docs/2021.2.1/install-core.md b/docs/2021.2.1/install-core.md
new file mode 100644
index 0000000000000000000000000000000000000000..2f7921cc63382d52dc73f6ff29a0f5c255dac3cb
--- /dev/null
+++ b/docs/2021.2.1/install-core.md
@@ -0,0 +1,73 @@
+## Core Installation
+
+Cryton Core uses environment variables for its settings.
+
+~~~~
+CRYTON_RABBIT_USERNAME=admin
+CRYTON_RABBIT_PASSWORD=mypass
+CRYTON_RABBIT_SRV_ADDR=cryton_rabbit
+CRYTON_RABBIT_SRV_PORT=5672
+CRYTON_DB_NAME=cryton
+CRYTON_DB_USERNAME=cryton
+CRYTON_DB_PASSWORD=cryton
+CRYTON_DB_HOST=cryton_pgbouncer
+Q_ATTACK_RESPONSE_NAME=cryton_core.attack.response
+Q_CONTROL_RESPONSE_NAME=cryton_core.control.response
+Q_EVENT_RESPONSE_NAME=cryton_core.event.response
+Q_CONTROL_REQUEST_NAME=cryton_core.control.request
+CRYTON_DEBUG=False
+CRYTON_PUBLIC_PORT=8000
+CRYTON_TZ=UTC
+CRYTON_RPC_TIMEOUT=1200
+~~~~
+
+### Using docker-compose
+
+Go into Cryton Core directory and run docker-compose, which will pull, build and start all necessary docker images.
+
+**If you've updated either docker-compose file or environment variables please check that they correspond.**
+
+For production environment, there are some other options needed (publishing ports to public IP addresses, persistent database data volume etc.).
+For production deployment, go to *Cryton Core* directory and use:
+
+~~~~
+docker-compose up -d
+~~~~
+
+Otherwise, use the default docker-compose file:
+
+~~~~
+docker-compose -f docker-compose.dev.yml up -d
+~~~~
+
+
+This process might take a while, especially if it is the first time you run it - image must be built.
+After a while you should see something like this:
+
+~~~~
+Creating network "cryton-core_default" with the default driver
+Creating cryton_rabbit ... done
+Creating cryton_db ... done
+Creating cryton_apache ... done
+Creating cryton_app ... done
+Creating cryton_pgbouncer ... done
+Creating cryton_listener ... don
+~~~~
+
+Everything should be set. Check if the installation was successful by either installing Cryton CLI or testing REST API with curl:
+
+~~~~
+curl localhost:8000
+~~~~
+
+The response should be:
+
+~~~~
+{"runs":"http://localhost:8000/cryton/api/v1/runs/","plans":"http://localhost:8000/cryton/api/v1/plans/","plan_executions":"http://localhost:8000/cryton/api/v1/plan_executions/","stages":"http://localhost:8000/cryton/api/v1/stages/","stage_executions":"http://localhost:8000/cryton/api/v1/stage_executions/","steps":"http://localhost:8000/cryton/api/v1/steps/","step_executions":"http://localhost:8000/cryton/api/v1/step_executions/","workers":"http://localhost:8000/cryton/api/v1/workers/","templates":"http://localhost:8000/cryton/api/v1/templates/","execution_variables":"http://localhost:8000/cryton/api/v1/execution_variables/"}
+~~~~
+
+You can also try to run tests inside the container:
+
+```
+docker exec --env CRYTON_DB_HOST='cryton_db' -it cryton_app pytest
+```
diff --git a/docs/2021.2.1/install-worker.md b/docs/2021.2.1/install-worker.md
new file mode 100644
index 0000000000000000000000000000000000000000..762a55a24d1dc5b81c36cdd114c2fbc28c3689fc
--- /dev/null
+++ b/docs/2021.2.1/install-worker.md
@@ -0,0 +1,127 @@
+## Worker Installation
+
+For this installation we are assuming installation on the same machine. Please update variables for your use case.
+
+Cryton Worker uses environment variables for it's settings.
+
+~~~~
+CRYTON_WORKER_MODULES_DIR=CHANGE_ME
+CRYTON_WORKER_DEBUG=False
+CRYTON_WORKER_LOG_CONFIG=CHANGE_ME_OPTIONALLY
+CRYTON_WORKER_MSFRPCD_PASS=toor
+CRYTON_WORKER_MSFRPCD_USERNAME=msf
+CRYTON_WORKER_MSFRPCD_PORT=55553
+CRYTON_WORKER_MSFRPCD_SSL=False
+CRYTON_WORKER_RABBIT_USERNAME=admin
+CRYTON_WORKER_RABBIT_PASSWORD=mypass
+CRYTON_WORKER_RABBIT_SRV_ADDR=CHANGE_ME
+CRYTON_WORKER_RABBIT_SRV_PORT=5672
+CRYTON_WORKER_RABBIT_WORKER_PREFIX=CHANGE_ME
+CRYTON_WORKER_CONSUMER_COUNT=3
+CRYTON_WORKER_PROCESSOR_COUNT=3
+CRYTON_WORKER_MAX_RETRIES=3
+CRYTON_WORKER_INSTALL_REQUIREMENTS=False
+~~~~
+
+These have to be updated in *.env* file before an installation and start up.
+`CRYTON_WORKER_MODULES_DIR` with the directory containing attack modules,
+`CRYTON_WORKER_RABBIT_SRV_ADDR` with the actual address of RabbitMQ server,
+`CRYTON_WORKER_RABBIT_WORKER_PREFIX` with desired prefix that will be used to communicate with the Worker,
+`CRYTON_WORKER_RABBIT_USERNAME` with RabbitMQ username and `CRYTON_WORKER_RABBIT_PASSWORD` with RabbitMQ password.
+
+## Manual (recommended)
+
+### Requirements
+
+- python3.8 (tested)
+- pipenv (optional)
+
+For manual installation all you need to do is go to *Cryton Worker*'s directory and **run the setup script**.
+
+~~~~
+python3.8 setup.py install
+~~~~
+
+Event better you can use virtual environment for installation, for example using pipenv:
+~~~~
+pipenv shell
+python setup.py install
+~~~~
+
+Use _develop_ if you wish to directly (locally) modify the code:
+
+```
+python setup.py develop
+```
+
+Everything should be set. Check if the installation was successful using:
+
+~~~~
+cryton-worker
+~~~~
+
+## Docker
+
+**NOTICE: This guide won't describe how to install or mount modules and applications used by them.
+Also, Triggers won't work, since the opened ports on Docker container can't be updated during uptime,
+you have to set them up before running the container.**
+
+Go to *Cryton Worker*'s directory and run docker-compose, which will pull, build and start all necessary docker images:
+~~~~
+cd cryton-worker/
+docker-compose up -d
+~~~~
+
+This process might take a while, especially if it is the first time you run it - Cryton-Worker image must be built.
+After a while you should see something like this:
+~~~~
+Creating cryton_worker ... done
+~~~~
+
+Everything should be set. Check if the installation was successful:
+
+~~~~
+user@localhost:~ /cryton-core $ docker-compose ps
+ Name Command State Ports
+---------------------------------------------
+cryton_worker cryton-worker Up
+~~~~
+
+If is in state `Restarting`, something went wrong. Please check if values in `.env` file are correct.
+
+## Modules installation
+To be able to **execute** (validate) **attack modules** you must download and save them into the same directory. Then update
+`CRYTON_WORKER_MODULES_DIR` environment variable to point to the correct location. Modules are loaded on Cryton Worker's start up.
+
+Modules directory example:
+```
+tree CRYTON_WORKER_MODULES_DIR
+CRYTON_WORKER_MODULES_DIR/
+├── mod_hydra
+│ └── mod.py
+└── mod_cmd
+ └── mod.py
+```
+
+As mentioned, Cryton Worker is used for validating and executing modules and in order for them to work you have to install their requirements.
+To do that you either install them manually inside Cryton Worker's environment, or you use Cryton Worker's CLI:
+```
+cryton-worker start --install-requirements
+```
+If this flag is specified each *requirements.txt* file inside the Worker's modules directory will be checked and installed.
+
+## Running Worker
+To start Worker use
+```
+cryton-worker start
+```
+and you should see something like:
+~~~~
+Starting..
+To exit press CTRL+C
+Connection does not exist. Retrying..
+Connection to RabbitMQ server established.
+[*] Waiting for messages.
+~~~~
+
+If you see an error. Please check if variables are correct and try to start Worker again.
diff --git a/docs/2021.2.1/instance.md b/docs/2021.2.1/instance.md
new file mode 100644
index 0000000000000000000000000000000000000000..110688bb5eff6472cf42051fe56c78ea9f75512b
--- /dev/null
+++ b/docs/2021.2.1/instance.md
@@ -0,0 +1,29 @@
+## Instance
+The second stage is creating an Instance. While Template contains unfilled variables (therefore the name "template"), Instance fills these things in by combining the Template with an **Inventory file**. This file contains all information that needs to be filled in the Template. After instantiation everything is ready to create a **Run**.
+
+**NOTE: After creating Plan instance only the Step arguments Jinja variables can be left unfilled and must be explicitly defined as string.**
+
+### Inventory files
+
+When you create a template, you don't always have all the information you need for directly executing it. Or you simply want to make it reusable for other people in their own environment. For the purpose of providing variability in templates we support **inventory files**. These inventory files can be used to provide variable values to Templates using **Jinja** language.
+
+The valid Plan file is written in INI format with variables in the Jinja format, which can be replaced during the instantiation process.
+
+Example of inventory file:
+
+```ini
+[names]
+stage1_target: 192.168.56.102
+```
+
+
+
+You can use it as in following example:
+
+```yaml
+ # Stage two: target is web server
+ - target: {{names.stage1_target}}
+```
+
+You can use Jinja variables everywhere in the Plan template.
+
diff --git a/docs/2021.2.1/logging.md b/docs/2021.2.1/logging.md
new file mode 100644
index 0000000000000000000000000000000000000000..80c731d46449aee7b6db13687dee14ba805c3155
--- /dev/null
+++ b/docs/2021.2.1/logging.md
@@ -0,0 +1,32 @@
+## Logging
+
+Cryton core allows logging into syslog. The logs adhere to following format:
+
+~~~~bash
+2021-05-18 11:19:20,012.012 INFO [139703594285896] {listener} [start] {"queue": "cryton_core.control.request", "event": "Queue declared and consuming", "logger": "cryton-debug", "level": "info", "timestamp": "2021-05-18T11:19:20.012152Z"},
+2021-05-18 11:19:20,014.014 INFO [139703594285896] {listener} [start] {"plan_name": "Example scenario", "plan_id": 129, "status": "success", "event": "plan created", "logger": "cryton", "level": "info", "timestamp": "2021-05-18T06:17:39.753017Z"},
+...
+~~~~
+
+Every Plan/Stage/Step change of state is logged for later analysis. For every Step the result is also stored, although std_out and std_err are (currently) not. They can be found in the database.
+
+You can choose from two loggers - **debug** or **prod**, which you can set by environment variable *CRYTON_LOGGER*.
+
+#### Logger handlers
+
+for **debug**:
+
+* RotatingFileHandler /var/log/cryton-debug.log
+* Console (std_out)
+
+for **prod**:
+
+* RotatingFileHandler /var/log/cryton.log
+* Console (std_out)
+
+When running in Docker, you can always check the logs by:
+
+```
+docker logs CONTAINER_NAME
+```
+
diff --git a/docs/2020.4.1/modules/mod_cmd.md b/docs/2021.2.1/modules/mod_cmd.md
similarity index 63%
rename from docs/2020.4.1/modules/mod_cmd.md
rename to docs/2021.2.1/modules/mod_cmd.md
index ea591164c7bc723b1e6b483a6207b960d3be3d77..944831dedc3ea0e33a1442bac6abdf656ad6f8fc 100644
--- a/docs/2020.4.1/modules/mod_cmd.md
+++ b/docs/2021.2.1/modules/mod_cmd.md
@@ -31,7 +31,9 @@ Description of input parameters for module.
| Parameter name | Parameter description |
| ---------------- | ---------------------- |
| `cmd` (required) | Command to be executed |
-| `output_file` (optional) | Where should be output file of module be stored, if not defined, output will be in the report file |
+| `session_id` (optional) | Msf session in which command should be executed |
+| `output_file`(optional) | Flag whether you want to save the output to a file in Cryton evidence directory (eg. true, false(default)) |
+| `std_out` (optional) | Flag whether you want to return `std_out`(raw output of command) (eg. true, false(default)) |
This module can use existing sessions with our [Cryton session management](https://cryton.gitlab-pages.ics.muni.cz/cryton-project/1.0/scenario/#session-management) feature.
@@ -40,27 +42,27 @@ This module can use existing sessions with our [Cryton session management](https
``` yaml
attack_module_args:
cmd: cat /etc/passwd
- output_file: /tmp/
+ session_id: 1
```
## Output
-Description of output.
+Description of module output.
-| Parameter name | Parameter description |
-| --------------- | ------------------------------------------------------- |
-| `file_contents` | File that contains output of command in `cmd` parameter |
+| Parameter name | Parameter description |
+| -------------- | ------------------------------------------------------------ |
+| `return_code` | 0 - success<br />-1 - fail |
+| `std_out` | Raw result of command |
+| `mod_err` | Error while running module |
+| `mod_out` | Module output that can be used as input for some modules |
-#### Example
+### Example
-**With `output_file` parameter:**
-
-```json
-{"mod_out": {"file_contents": "path/to/file"}}
-```
-
-**Without `output_file` parameter:**
-
-```json
-{"mod_out": {"cmd_out": "command output"}}
```
+{
+ 'return_code': 0,
+ 'std_out': 'contents of passwd file on target'
+ 'mod_err': '',
+ 'mod_out': same as std_out
+}
+```
\ No newline at end of file
diff --git a/docs/2021.2.1/modules/mod_medusa.md b/docs/2021.2.1/modules/mod_medusa.md
new file mode 100644
index 0000000000000000000000000000000000000000..8bdc452269a076263a3822424be77a8b1d88a9b5
--- /dev/null
+++ b/docs/2021.2.1/modules/mod_medusa.md
@@ -0,0 +1,95 @@
+# mod_medusa
+
+This module implements attacking capabilities of Medusa bruteforce tool.
+
+## Requirements
+
+System requirements (those not listed in requirements.txt for python).
+
+For this module to function properly, [Medusa](https://github.com/jmk-foofus/medusa) need to be installed.
+
+## Input parameters
+
+Description of input parameters for module.
+
+| Parameter name | Parameter description |
+| ------------------------ | ------------------------------------------------------------ |
+| `target` | Bruteforce target (must be set when not using command) |
+| `mod` (optional) | Specified mod(service) you want to use to attack (default ssh) |
+| `output_file` (optional) | Flag whether you want to save the output to a file in Cryton evidence directory (eg. true, false(default)) |
+| `std_out` (optional) | Flag whether you want to return `std_out`(raw medusa output) (eg. true, false(default)) |
+| `credentials` (optional) | Parameters that can be used under this key are in table below (default are wordlists in module folder) |
+| `tasks` (optional) | Total number of login pairs to be tested concurrently (default is 4) |
+
+Parameters that can be used under `credentials`.
+
+| Parameter name | Parameter description |
+| --------------- | ------------------------------------------------------------ |
+| `username` | Username to use for bruteforce |
+| `password` | Password to use for bruteforce |
+| `username_list` | Absolute path to file with usernames (default is username wordlist in mod folder) |
+| `password_list` | Absolute path to file with passwords (default is password wordlist in mod folder) |
+| `combo_list` | Absolute path to file with login pairs - user:password (official format can be found in http://foofus.net/goons/jmk/medusa/medusa.html). **Cannot be combined with other input parameters under `credentials`!** |
+
+Parameters for custom command usage
+
+| Parameter name | Parameter description |
+| ------------------------ | ------------------------------------------------------------ |
+| `command` | Medusa command with syntax as in command line. If you specify '-o' parameter `output_file` will be True. **Cannot be combined with other input parameters!** |
+| `output_file` (optional) | Flag whether you want to save the output to a file in Cryton evidence directory (eg. true, false(default)) |
+
+#### Example yaml(s)
+
+```yaml
+attack_module_args:
+ target: 127.0.0.1
+ credentials:
+ username: admin
+ password: pass
+ tasks: 4
+```
+
+```yaml
+attack_module_args:
+ target: 127.0.0.1
+ credentials:
+ combo_list: absolute/path/to/file
+ tasks: 4
+```
+
+```yaml
+attack_module_args:
+ command: medusa -t 4 -u vagrant -p vagrant -O cryton_default -h 127.0.0.1 -M ssh
+```
+
+## Output
+
+Description of module output.
+
+| Parameter name | Parameter description |
+| -------------- | ------------------------------------------------------------ |
+| `return_code` | 0 - success<br />-1 - fail |
+| `std_out` | Raw output of hydra bruteforce |
+| `mod_err` | Error while running hydra bruteforce |
+| `mod_out` | Parsed module output with useful data that can be used as input for some modules |
+
+### Mod_out
+
+Description of `mod_out` output parameter
+
+| Parameter name | Parameter description |
+| -------------- | ------------------------------------------------------------ |
+| `username` | Username found during bruteforce |
+| `password` | Password found during bruteforce |
+| `credentials` | If there are more than one login credentials found, they are returned in form of user:password pairs |
+
+### Example
+
+```
+{
+ 'return_code': 0,
+ 'std_out': 'Medusa v2.2 [http://www.foofus.net] (C) JoMo-Kun / Foofus Networks <jmk@foofus.net>\n\nACCOUNT CHECK: [ssh] Host: 127.0.0.1 (1 of 1, 0 complete) User: admin (1 of 1, 0 complete) Password: pass (1 of 1 complete)\nACCOUNT FOUND: [ssh] Host: 127.0.0.1 User: vagrant Password: vagrant [SUCCESS]\n',
+ 'mod_err': '',
+ 'mod_out': {'username': 'admin', 'password': 'pass'}
+}
+```
\ No newline at end of file
diff --git a/docs/2021.2.1/modules/mod_msf.md b/docs/2021.2.1/modules/mod_msf.md
new file mode 100644
index 0000000000000000000000000000000000000000..376b336706121ff48a267db91076b015aeabb4ed
--- /dev/null
+++ b/docs/2021.2.1/modules/mod_msf.md
@@ -0,0 +1,70 @@
+# mod_msf
+
+Module for orchestrating Metasploit Framework.
+
+## Requirements
+
+System requirements (those not listed in requirements.txt for python).
+
+For this module to function properly, [Metasploit-framework](https://github.com/rapid7/metasploit-framework/wiki/Nightly-Installers) needs to be installed.
+
+After a successful installation of Metasploit-framework, you need to load msgrpc plugin. Easiest way to do this to open your terminal and run `msfrpcd` with `-P toor` to use password and `-S` to turn off SSL (depending on configuration in Worker config file).
+
+**Optional:**
+
+Another option is to run Metasploit using `msfconsole` and load msgrpc plugin using this command:
+
+````bash
+load msgrpc ServerHost=127.0.0.1 ServerPort=55553 User=msf Pass='toor' SSL=true
+````
+
+This is just default, feel free to change the parameters to suit your needs, but keep in mind that they must match your worker config file.
+
+After successfully loading the msgrpc plugin, you are all set and ready to use this module.
+
+## Input parameters
+
+Description of input parameters for module.
+
+| Parameter name | Parameter description |
+| ------------------- | ------------------------------------------------------------ |
+| `exploit` | Exploit present in Metasploit library to be used |
+| `std_out` (optional) | Flag whether you want to return `std_out`(raw metasploit output) (eg. true, false(default)) |
+| `exploit_arguments` | Custom list of Metasploit specific arguments (eg. RHOSTS, RPORT) |
+
+As a default value for RHOSTS, Stage "target" is used.
+
+This module can create sessions using our [Cryton session management](https://cryton.gitlab-pages.ics.muni.cz/cryton-project/1.0/scenario/#session-management) feature.
+
+### Example yaml(s)
+
+```yaml
+attack_module_args:
+ exploit: auxiliary/scanner/ssh/ssh_login
+ exploit_arguments:
+ RHOSTS: 127.0.0.1
+ USERPASS_FILE: /usr/share/metasploit-framework/data/wordlists/root_userpass.txt
+```
+
+## Output
+
+Description of module output.
+
+| Parameter name | Parameter description |
+| -------------- | ------------------------------------------------------------ |
+| `return_code` | 0 - success<br />-1 - fail |
+| `std_out` | Raw output of msf exploit |
+| `mod_err` | Error while running msf exploit |
+| `mod_out` | Same as std_out |
+
+### Example
+
+```
+{
+ 'return_code': 0,
+ 'std_out': "RHOSTS => 127.0.0.1\nUSERNAME => vagrant\nPASSWORD => vagrant\n[*] Auxiliary module running as background job 4.\n[*] 127.0.0.1:22 - Starting bruteforce\n[+] 127.0.0.1:22 - Success: 'vagrant:vagrant' 'uid=1000(vagrant) gid=1000(vagrant) groups=1000(vagrant),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev),119(bluetooth),122(kali-trusted),133(scanner),142(kaboxer),143(docker) Linux kali 5.10.0-kali7-amd64 #1 SMP Debian 5.10.28-1kali1 (2021-04-12) x86_64 GNU/Linux '\n[*] Command shell session 2 opened (127.0.0.1:35199 -> 127.0.0.1:22) at 2021-05-22 22:57:36 +0200\n[*] Scanned 1 of 1 hosts (100% complete)\n",
+ 'mod_err': None,
+ 'mod_out': "RHOSTS => 127.0.0.1\nUSERNAME => vagrant\nPASSWORD => vagrant\n[*] Auxiliary module running as background job 4.\n[*] 127.0.0.1:22 - Starting bruteforce\n[+] 127.0.0.1:22 - Success: 'vagrant:vagrant' 'uid=1000(vagrant) gid=1000(vagrant) groups=1000(vagrant),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev),119(bluetooth),122(kali-trusted),133(scanner),142(kaboxer),143(docker) Linux kali 5.10.0-kali7-amd64 #1 SMP Debian 5.10.28-1kali1 (2021-04-12) x86_64 GNU/Linux '\n[*] Command shell session 2 opened (127.0.0.1:35199 -> 127.0.0.1:22) at 2021-05-22 22:57:36 +0200\n[*] Scanned 1 of 1 hosts (100% complete)\n"
+}
+
+```
\ No newline at end of file
diff --git a/docs/2021.2.1/modules/mod_nmap.md b/docs/2021.2.1/modules/mod_nmap.md
new file mode 100644
index 0000000000000000000000000000000000000000..8dd813982d52cac7daa755487129ca1cf3384ad3
--- /dev/null
+++ b/docs/2021.2.1/modules/mod_nmap.md
@@ -0,0 +1,63 @@
+# mod_nmap
+
+This module implemets scanning capabilities of Nmap.
+
+It is scanning target's ports. By default it scans the most common ports and returns a list with all ports and their parameters.
+
+## Requirements
+
+List of system requirements (those not listed in requirements.txt for python).
+
+For this module to function properly, [Nmap](https://github.com/nmap/nmap) need to be installed.
+
+## Input parameters
+
+Description of input parameters for module.
+
+| Parameter name | Parameter description |
+| ---------------------------- | ------------------------------------------------------------ |
+| `target` | Scan target (eg. 127.0.0.1) |
+| `ports` (optional) | List of ports to be scanned (default scans most common ports) (eg. [80, 443]) |
+| `port_parameters` (optional) | Check if found ports match your desired parameters. The desired port must be added into 'ports'). Options with examples: {`"portid": 22, "host": "127.0.0.1", "protocol": "tcp", "state": "open", "reason":"syn-ack", "service": {"name": "ssh", "product": "OpenSSH", "version": "8.4p1 Debian 3", "extrainfo": "protocol 2.0", "ostype": "Linux", "method": "probed", "conf": "10"}, "cpe": "cpe:/o:linux:linux_kernel"`}. |
+| `options` (optional) | Additional Nmap parameters (parameter -sV already included) (eg. -T4) |
+| `output_file` (optional) | Flag whether you want to save the output to a file in Cryton evidence directory (eg. true, false(default)) |
+| `std_out` (optional) | Flag whether you want to return `std_out`(raw nmap output) (eg. true, false(default)) |
+
+### Example yaml(s)
+
+```yaml
+attack_module_args:
+ target: 127.0.0.1
+ ports:
+ - 22
+ - 21
+ port_parameters:
+ - portid: 22
+ state: open
+ service:
+ product: OpenSSH
+ ostype: Linux
+ options: -T4
+```
+
+## Output
+
+Description of module output.
+
+| Parameter name | Parameter description |
+| -------------- | ------------------------------------------------------------ |
+| `return_code` | 0 - success<br />-1 - fail |
+| `std_out` | Raw output of Nmap scan |
+| `mod_err` | Error while running Nmap scan |
+| `mod_out` | Parsed module output with useful data that can be used as input for some modules, for example filtered ports with `port_parameters` input parameter |
+
+### Example
+
+```
+{
+ 'return_code': 0,
+ 'std_out': {'127.0.0.1': {'osmatch': {}, 'ports': [{'protocol': 'tcp', 'portid': '22', 'state': 'open', 'reason': 'syn-ack', 'reason_ttl': '0', 'service': {'name': 'ssh', 'product': 'OpenSSH', 'version': '8.1p1 Debian 1', 'extrainfo': 'protocol 2.0', 'ostype': 'Linux', 'method': 'probed', 'conf': '10'}, 'cpe': [{'cpe': 'cpe:/o:linux:linux_kernel'}], 'scripts': []}, {'protocol': 'tcp', 'portid': '80', 'state': 'closed', 'reason': 'conn-refused', 'reason_ttl': '0', 'service': {'name': 'http', 'method': 'table', 'conf': '3'}, 'scripts': []}], 'hostname': [{'name': 'localhost', 'type': 'PTR'}], 'macaddress': None, 'state': {'state': 'up', 'reason': 'conn-refused', 'reason_ttl': '0'}}, 'stats': {'scanner': 'nmap', 'args': '/usr/bin/nmap -oX - -sV -T4 -p22,80 127.0.0.1', 'start': '1614274118', 'startstr': 'Thu Feb 25 18:28:38 2021', 'version': '7.80', 'xmloutputversion': '1.04'}, 'runtime': {'time': '1614274119', 'timestr': 'Thu Feb 25 18:28:39 2021', 'elapsed': '0.26', 'summary': 'Nmap done at Thu Feb 25 18:28:39 2021; 1 IP address (1 host up) scanned in 0.26 seconds', 'exit': 'success'}},
+ 'mod_err': None,
+ 'mod_out': {'127.0.0.1': {'osmatch': {}, 'ports': [{'protocol': 'tcp', 'portid': '22', 'state': 'open', 'reason': 'syn-ack', 'reason_ttl': '0', 'service': {'name': 'ssh', 'product': 'OpenSSH', 'version': '8.4p1 Debian 3', 'extrainfo': 'protocol 2.0', 'ostype': 'Linux', 'method': 'probed', 'conf': '10'}, 'cpe': [{'cpe': 'cpe:/o:linux:linux_kernel'}], 'scripts': []}], 'hostname': [{'name': 'localhost', 'type': 'PTR'}], 'macaddress': None, 'state': {'state': 'up', 'reason': 'conn-refused', 'reason_ttl': '0'}}}
+}
+```
\ No newline at end of file
diff --git a/docs/2020.4.1/modules/mod_ssh_session.md b/docs/2021.2.1/modules/mod_ssh_session.md
similarity index 100%
rename from docs/2020.4.1/modules/mod_ssh_session.md
rename to docs/2021.2.1/modules/mod_ssh_session.md
diff --git a/docs/2020.4.1/plan.md b/docs/2021.2.1/plan.md
similarity index 96%
rename from docs/2020.4.1/plan.md
rename to docs/2021.2.1/plan.md
index e7b1e230a75a2bdbff33ae76bb46b56f4492a128..b4c2ee00faf98fe2c9659e842f5d24b22642b560 100644
--- a/docs/2020.4.1/plan.md
+++ b/docs/2021.2.1/plan.md
@@ -1,6 +1,7 @@
-
Plan is the basic unit of attack scenario. It contains name and owner of the Plan and a list of Stages.
+
+
### Example
```yaml
@@ -29,7 +30,6 @@ plan:
attack_module: mod_medusa
attack_module_args:
target: 127.0.0.1
- open_ports: $parent.open_ports
username: vagrant
password: vagrant
next:
@@ -54,4 +54,4 @@ plan:
use_named_session: session_to_target_1
attack_module_args:
cmd: cat /etc/passwd
-```
+```
\ No newline at end of file
diff --git a/docs/2021.2.1/reporting.md b/docs/2021.2.1/reporting.md
new file mode 100644
index 0000000000000000000000000000000000000000..83a514f36b3511134da8c7eedb5c2b930ff1bd2e
--- /dev/null
+++ b/docs/2021.2.1/reporting.md
@@ -0,0 +1,127 @@
+After the Run has successfully ended (or not) you can **generate a report** with every Steps output and result. When you have multiple plan executions in a single run (when utilizing multiple Workers), you can compare each execution and use this insight to eg. score each team in a *cyber security exercise.*
+
+You can see an example report here:
+
+```yaml
+plan_name: Example scenario
+state: FINISHED
+start_time: '2020-11-01T22:20:10.208170'
+finish_time: null
+pause_time: null
+plan_executions:
+- id: 1
+ stage_name: Example scenario
+ state: FINISHED
+ start_time: '2020-11-01T22:20:09.964302'
+ finish_time: null
+ pause_time: null
+ worker_id: 1
+ worker_name: test
+ evidence_dir: /root/.cryton/evidence/plan_001-Example_scenario/run_1/worker_test
+ stage_executions:
+ - id: 1
+ stage_name: stage-one
+ state: FINISHED
+ start_time: '2020-11-01T22:20:14.964302'
+ finish_time: null
+ pause_time: null
+ step_executions:
+ - id: 1
+ step_name: scan-localhost
+ state: FINISHED
+ start_time: '2020-11-01T22:20:15.083197'
+ finish_time: '2020-11-01T22:21:10.279528'
+ result: OK
+ mod_out:
+ open_ports:
+ ssh: '22'
+ mod_err: No error
+ std_out: '[{"host": "127.0.0.1", "hostname": "localhost", "hostname_type": "PTR",
+ "protocol": "tcp", "port": "22", "name": "ssh", "state": "open", "product":
+ "OpenSSH", "extrainfo": "protocol 2.0", "reason": "syn-ack", "version": "8.1p1
+ Debian 1", "conf": "10", "cpe": "cpe:/o:linux:linux_kernel"}]'
+ std_err: null
+ evidence_file: No evidence
+ valid: false
+ - id: 2
+ step_name: bruteforce
+ state: FINISHED
+ start_time: '2020-11-01T22:21:10.410417'
+ finish_time: '2020-11-01T22:21:13.496688'
+ result: OK
+ mod_out:
+ password: vagrant
+ username: vagrant
+ mod_err: No error
+ std_out: '{''username'': ''vagrant'', ''password'': ''vagrant''}'
+ std_err: null
+ evidence_file: /tmp/1604269273
+ valid: false
+ - id: 3
+ step_name: ssh-session
+ state: FINISHED
+ start_time: '2020-11-01T22:21:13.642667'
+ finish_time: '2020-11-01T22:21:24.913794'
+ result: OK
+ mod_out: null
+ mod_err: null
+ std_out: 'RHOSTS => 127.0.0.1
+
+ PASSWORD => vagrant
+
+ USERNAME => vagrant
+
+ [*] Auxiliary module running as background job 45.
+
+ [+] 127.0.0.1:22 - Success: ''vagrant:vagrant'' ''''
+
+ [*] Command shell session 46 opened (127.0.0.1:46721 -> 127.0.0.1:22) at 2020-11-01
+ 23:21:23 +0100
+
+ [*] Scanned 1 of 1 hosts (100% complete)
+
+ '
+ std_err: null
+ evidence_file: No evidence
+ valid: false
+ - id: 4
+ step_name: session-cmd
+ state: FINISHED
+ start_time: '2020-11-01T22:21:25.028513'
+ finish_time: '2020-11-01T22:21:29.186426'
+ result: UNKNOWN
+ mod_out:
+ cmd_out: 'Linux kali 5.3.0-kali2-amd64 #1 SMP Debian 5.3.9-3kali1 (2019-11-20)
+ x86_64
+
+ The programs included with the Kali GNU/Linux system are free software;
+ the exact distribution terms for each program are described in the
+ individual files in /usr/share/doc/*/copyright.
+
+ Kali GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
+ permitted by applicable law.
+ root:x:0:0:root:/root:/bin/bash
+ daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
+ ...
+ '
+ mod_err: No error
+ std_out: 'Linux kali 5.3.0-kali2-amd64 #1 SMP Debian 5.3.9-3kali1 (2019-11-20)
+ x86_64
+
+
+ The programs included with the Kali GNU/Linux system are free software;
+ the exact distribution terms for each program are described in the
+ individual files in /usr/share/doc/*/copyright.
+
+ Kali GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
+ permitted by applicable law.
+ root:x:0:0:root:/root:/bin/bash
+ daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
+ ...
+ '
+ std_err: null
+ evidence_file: No evidence
+ valid: false
+
+```
+
diff --git a/docs/2021.2.1/requirements.md b/docs/2021.2.1/requirements.md
new file mode 100644
index 0000000000000000000000000000000000000000..954afe6c06e6183f7c6ff3fcd3a5f7a280a25bd8
--- /dev/null
+++ b/docs/2021.2.1/requirements.md
@@ -0,0 +1,43 @@
+# Requirements
+For being able to execute the attack scenarios, you need to install the **Cryton core**,
+**Cryton worker** package and copy the **modules** you wish to execute in the attack scenarios
+into directory specified in *Cryton Worker*. Also, for easier control over Cryton's execution
+you should install **Cryton CLI** package.
+
+So far the only supported and tested OS is Kali Linux with version 2021.1, however other distributions
+shouldn't matter too much, since the *Cryton Core* component runs in Docker and *Cryton Worker* is written
+in pure Python3. Same applies for *Cryton CLI* and *Cryton Modules*.
+
+## Docker and Docker compose setup
+
+**Required packages**
+
+- docker.io
+- docker-compose
+
+Make sure you have *Docker* and *Docker compose* installed:
+
+~~~~
+sudo apt install docker.io docker-compose
+~~~~
+
+Add yourself to the group docker, so you can work with docker CLI without sudo:
+
+~~~~
+sudo groupadd docker
+sudo usermod -aG docker $USER
+newgrp docker
+docker run hello-world
+~~~~
+
+## Manual setup
+
+**Required packages**
+
+- pipenv
+
+Make sure you have *Pipenv* installed:
+
+````
+sudo apt install pipenv
+````
\ No newline at end of file
diff --git a/docs/2020.4.1/rest.md b/docs/2021.2.1/rest.md
similarity index 99%
rename from docs/2020.4.1/rest.md
rename to docs/2021.2.1/rest.md
index 6bc322df4bcf507aacf34111b8293e3fe3e9c19a..163a36e09531298da33a5f236e4f62e7630e4f8c 100644
--- a/docs/2020.4.1/rest.md
+++ b/docs/2021.2.1/rest.md
@@ -3,12 +3,9 @@ This document provides documentation of Cryton REST API endpoints. It was automa
If you are interested in Swagger interactive documentation, browse to `/doc` endpoint on Cryton REST API.
-## Version: v1
-
-**Contact information:**
-nutar@ics.muni.cz
-
+
+## Version: v1
### /plan_executions/
@@ -1061,4 +1058,4 @@ Delete Step specified by ID
| create_named_session | string | | No |
| use_named_session | string | | No |
| use_any_session_to_target | string | | No |
-| stage_model | string (uri) | | Yes |
+| stage_model | string (uri) | | Yes |
\ No newline at end of file
diff --git a/docs/2020.4.1/exec-vars.md b/docs/2021.2.1/run-configuration.md
similarity index 82%
rename from docs/2020.4.1/exec-vars.md
rename to docs/2021.2.1/run-configuration.md
index dece477972e8c555513f5144b7342ffaa1f88ca2..571a2d88123a68139ed4c59ffea123807c6332d8 100644
--- a/docs/2020.4.1/exec-vars.md
+++ b/docs/2021.2.1/run-configuration.md
@@ -1,4 +1,4 @@
-### Execution variables
+## Execution variables
If you want to assign different values for each PlanExecution in Run, you can use execution variables.
Basically when you're creating Plan template instead of filling all arguments, you can instead insert Jinja variable. For example:
@@ -10,11 +10,9 @@ target: "{{ my_var }}"
**IMPORTANT: Those variables must be defined as string using single or double quotes.**
-And before you execute Run (and its PlanExecution(s)), you can upload your variable(s). (see [CLI](interfaces.md#execution-variables)) File example:
+And before you execute Run (and its PlanExecution(s)), you can upload your variable(s). (see [CLI](cli.md#execution-variables)) File example:
```
{"my_var":"localhost"}
```
If a variable cannot be filled it's left untouched.
-
-###
\ No newline at end of file
diff --git a/docs/2021.2.1/run-control.md b/docs/2021.2.1/run-control.md
new file mode 100644
index 0000000000000000000000000000000000000000..5a9eb3ad4d041180b875244c69d1c0c596d3d0a0
--- /dev/null
+++ b/docs/2021.2.1/run-control.md
@@ -0,0 +1,24 @@
+Following are the actions you can do on created Run.
+
+### Execute
+
+Basic action you can do is **Execute** the Run. This will start it instantly. What does that mean?
+
+* Delta triggered Stages are scheduled
+* HTTP triggers are started on Workers
+* Run state is set to RUNNING
+
+### Schedule, Reschedule, Unschedule
+
+Schedule action does just that - it **schedules** an *Execute* action at a given time. If you want to change the time of your execution, you can still **reschedule** it or simply **unschedule** it and leave it in prepared state.
+
+### Pause, Unpause
+
+Anytime during Run execution you can **pause** it. To continue the Run, simply issue **unpause** command.
+
+###
+
+
+
+
+
diff --git a/docs/2021.2.1/run.md b/docs/2021.2.1/run.md
new file mode 100644
index 0000000000000000000000000000000000000000..f7cd15a4e3dc29d9fd67500f633b03f30d67b746
--- /dev/null
+++ b/docs/2021.2.1/run.md
@@ -0,0 +1,4 @@
+## Run
+When you finally have an Instance stored in database, you can create a new Run. For every Worker a new PlanExecution is created.
+The reason behind this is storage of execution history, so it is possible to compare results in Run and usage of different variables for PlanExecutions.
+As mentioned before, you can leave Step argument as an empty Jinja variable. Now, before execution, you can use different values for each PlanExecution.
\ No newline at end of file
diff --git a/docs/2020.4.1/scenario.md b/docs/2021.2.1/scenario.md
similarity index 100%
rename from docs/2020.4.1/scenario.md
rename to docs/2021.2.1/scenario.md
diff --git a/docs/2021.2.1/session-mngmt.md b/docs/2021.2.1/session-mngmt.md
new file mode 100644
index 0000000000000000000000000000000000000000..e020cb6446ba4075dd0c622fe63b02fc559e1059
--- /dev/null
+++ b/docs/2021.2.1/session-mngmt.md
@@ -0,0 +1,68 @@
+## Session management
+
+One of the unique features of Cryton is ability to create and use *sessions* - connections to the target systems.
+When you successfully exploit a running network service on your target machine (victim), you open a connection to it.
+In Cryton, this connection can be given name and then used during the Plan execution in any Step (which is executed on the same Worker node and supports this functionality).
+Metasploit Framework session management is used for storing and interacting with sessions, and therefore must be available and running on the Worker node.
+
+```yaml
+- name: step1
+ attack_module: ...
+ attack_module_arguments:
+ create_named_session: session_to_target_1
+ ...
+- name: step2
+ attack_module: ...
+ attack_module_arguments:
+ use_named_session: session_to_target_1
+ ...
+```
+
+In the example above, step1 creates a named session *session_to_target_1* (in case it succeeds).
+It's Metasploit ID gets stored in database and can be used anywhere in the Plan, not only in following Step (as seen in example).
+When the Plan creates multiple sessions to the same target, and the attacker does not care which he is using, *use_any_session_to_target* parameter can be used.
+
+```yaml
+- name: step1
+ attack_module: ...
+ attack_module_arguments:
+ use_any_session_to_target: 192.168.56.22
+ ...
+```
+
+
+
+## Plan example
+
+```yaml
+---
+plan:
+ name: Session example
+ owner: testname
+ stages:
+ - name: stage-one
+ trigger_type: delta
+ trigger_args:
+ seconds: 5
+ steps:
+ - name: ssh-session
+ is_init: true
+ attack_module: mod_msf
+ attack_module_args:
+ create_named_session: session_to_target_1
+ exploit: auxiliary/scanner/ssh/ssh_login
+ exploit_arguments:
+ RHOSTS: 127.0.0.1
+ USERNAME: vagrant
+ PASSWORD: vagrant
+ next:
+ - type: result
+ value: OK
+ step: session-cmd
+ - name: session-cmd
+ attack_module: mod_cmd
+ attack_module_args:
+ use_named_session: session_to_target_1
+ cmd: cat /etc/passwd
+```
+
diff --git a/docs/2021.2.1/stage.md b/docs/2021.2.1/stage.md
new file mode 100644
index 0000000000000000000000000000000000000000..3c796cec677787ca4a99a20804b501d78253359c
--- /dev/null
+++ b/docs/2021.2.1/stage.md
@@ -0,0 +1,97 @@
+Stage is a unit defined by a target and a time of start. It contains a list of attack Steps.
+
+
+
+## Triggering
+
+### trigger_type
+
+A type of trigger to be used. Available triggers are:
+
+| Type | Meaning |
+| -------------- | ------------------------------------------------------------ |
+| `delta` | Schedule execution for specific time after plan start, eg. `minutes: 30` |
+| `HTTPListener` | Stage will be executed on specific data received in HTTP request (GET/POST) on the listener |
+
+### trigger_args
+
+Trigger arguments, that are specific for every type of trigger.
+
+**Delta**
+
+```yaml
+trigger_args:
+ hours: 0 # Wait for x hours.
+ minutes: 0 # Wait for x minutes.
+ seconds: 0 # Wait for x seconds.
+```
+
+**HTTPListener**
+
+```yaml
+trigger_args:
+ host: localhost # Address of the listener from Worker's perspective.
+ port: 8082 # Port of the listener from Worker's perspective.
+ routes: # List of routes listener will check for requests.
+ - path: /index # Request's path.
+ method: GET # Request's allowed method.
+ parameters: # Request's required parameters.
+ - name: parameter # Parameter's name.
+ value: value # Parameter's value.
+```
+
+## Dependencies
+
+To ensure your Stage will be executed at the correct time, you can choose to check if some other Stage has already
+finished, before its execution. All you have to do is define `depends_on` argument.
+
+```yaml
+- name: stage-name
+ depends_on:
+ - other-stage
+```
+
+## Example
+
+```yaml
+- name: stage-one
+ trigger_type: delta
+ trigger_args:
+ minutes: 5
+ steps:
+ - name: scan-localhost
+ is_init: true
+ attack_module: infrastructure/scan/mod_nmap
+ attack_module_args:
+ ports:
+ - 22
+ next:
+ - type: result
+ value: OK
+ step: ssh-bruteforce
+```
+
+```yaml
+- name: stage-one
+ trigger_type: delta
+ trigger_args:
+ minutes: 5
+ steps:
+ ...
+
+- name: stage-two
+ depends_on:
+ - stage-one
+ trigger_type: HTTPListener
+ trigger_args:
+ host: localhost
+ port: 8082
+ routes:
+ - path: /index
+ method: GET
+ parameters:
+ - name: parameter
+ value: value
+ steps:
+ ...
+```
\ No newline at end of file
diff --git a/docs/2020.4.1/step.md b/docs/2021.2.1/step.md
similarity index 66%
rename from docs/2020.4.1/step.md
rename to docs/2021.2.1/step.md
index fc5abe096debbe24f918c77b070e190c526fb9b0..ed4adabbd946e5fa949ba2e21a62bcfad50a2ed5 100644
--- a/docs/2020.4.1/step.md
+++ b/docs/2021.2.1/step.md
@@ -1,13 +1,13 @@
Let's start with Step. Step is an execution of attack module. Every step can have a successor of which execution will follow according to provided conditions.
-### Conditional execution
+## Conditional execution
To be able to actually execute Attack scenario according to some execution tree, Steps provide a way to be executed according to specified conditions. There are many types of conditions that can be used. To use them in designint a Template, a list of dictionaries **containing** params **type**, **value**, **step** must be provided.
Following are types of conditions together with descriptions of possible values.
-##### type
+### type
Which value you want to compare, according to output of the parent Step.
@@ -21,7 +21,7 @@ Following are types of conditions together with descriptions of possible values.
| `mod_err` | Module error output. |
| `any` | Any step's result will be taken as valid. |
-##### value
+### value
The desired value of the selected type. Can be defined as string (one value) or list of strings (multiple values).
@@ -37,7 +37,7 @@ Following are types of conditions together with descriptions of possible values.
-##### step
+### step
Name of the Step's successor(s).
Can be string (one successor) or list of strings (multiple successors).
@@ -50,14 +50,28 @@ next:
step: step-to-execute
```
-### Output sharing
+## Output sharing
+
+Output sharing is used for sharing gained data (*mod_out*) between multiple steps. To go through the data we use modified version of dot notation.
+
+For example imagine following dictionary (Python data structure)
+```python
+{"credentials": [{"username": "admin", "password": "securePassword"}]}
+```
+If we wanted to access it and get **password** for *admin* user using our version of dot notation, we would use `credentials[0].password` which would return *securePassword* string.
+
+This brings in some limitations:
+
+- keys are separated using `.`
+- key can't be in format `[integer]` (regex representation: `^\[[0-9]+]$`) as it represents list (array) index
+- list (array) index can be defined multiple times in the same key for example `myKey[1][1]`, however must be defined at its end (regex representation: `((\[[0-9]+])+$)`)
There are two techniques for sharing outputs of modules between steps:
* **output_prefix**
* **output_mapping**
-#### Output prefix
+### Output prefix
By default, the prefix string is set to name of the step. Using its name, any other step can query its output (mod_out of its attack module execution) and use it in its arguments.
@@ -82,7 +96,8 @@ For example:
password: $custom_prefix.password
```
-Your prefix can be any string you want, but it **cannot contain $ and . signs**. Also, there is a special prefix named **parent**, which simply takes output from parent step execution (which executed current step).
+Your prefix can be any string you want, but it **cannot contain $ and . signs**. Also, there is a special prefix named **parent**, which
+simply takes output from parent step execution (which executed current step).
```yaml
- name: stepA
@@ -97,8 +112,10 @@ Your prefix can be any string you want, but it **cannot contain $ and . signs**.
username: $parent.var
```
-#### Output mapping
-Sometimes you do not care from which module you receive information. Step A and Step B can both return a stolen authentication token. For this reason you can use ```output_prefix```. But there is an obvious problem! What if both steps return this value under different name, eg. ```token``` and ```auth_token```? Prefix would not help you much in this situation. For this reason there is a ```output_mapping``` mechanism.
+### Output mapping
+Sometimes you do not care from which module you receive information. Step A and Step B can both return a stolen authentication token. For this reason you can use ```output_prefix```.
+But there is an obvious problem! What if both steps return this value under different name, eg. ```token``` and ```auth_token```? Prefix would not help you much in this situation.
+For this reason there is a ```output_mapping``` mechanism.
```yaml
- name: step_a
# Returns 'token'
@@ -119,7 +136,7 @@ Sometimes you do not care from which module you receive information. Step A and
attack_module_args:
token: $steal.stolen_token
```
-### Example
+## Example
```yaml
- name: scan-localhost
@@ -132,6 +149,11 @@ Sometimes you do not care from which module you receive information. Step A and
- type: result
value: OK
step: ssh-bruteforce
+- name: ssh-bruteforce
+ attack_module: bruteforce/mod_hydra
+ attack_module_args:
+ username: root
+ password: toor
```
```yaml
@@ -140,5 +162,24 @@ Sometimes you do not care from which module you receive information. Step A and
attack_module: misc/mod_cmd
attack_module_args:
cmd: cat /etc/passwd
- use_any_session_to_target: 192.168.56.103
+ use_any_session_to_target: 192.168.56.103
+```
+
+## Execution variables
+
+If you want to assign different values for each PlanExecution in Run, you can use execution variables.
+Basically when you're creating Plan template instead of filling all arguments, you can instead insert Jinja variable. For example:
+
+```
+attack_module_args:
+target: "{{ my_var }}"
+```
+
+**IMPORTANT: Those variables must be defined as string using single or double quotes.**
+
+And before you execute Run (and its PlanExecution(s)), you can upload your variable(s). (see [CLI](cli.md#execution-variables)) File example:
+
+```
+{"my_var":"localhost"}
```
+If a variable cannot be filled it's left untouched.
diff --git a/docs/2021.2.1/template.md b/docs/2021.2.1/template.md
new file mode 100644
index 0000000000000000000000000000000000000000..839ce43c071ca0ac76fb8b47f32dd71fd615d9b7
--- /dev/null
+++ b/docs/2021.2.1/template.md
@@ -0,0 +1,20 @@
+The most important part is creating a Template. This is basically a Plan object written in YAML format. You can find a detailed description of this format in section [Plan](#plan).
+
+Template itself is not a fully described Attack scenario. The structure of the Attack (the execution tree) is correct, but there are still unfilled places, eg. IP addresses of targets or some module arguments. This way an Attack Template can be designed before knowing these details and used in multiple different environments.Template
+
+
+
+
+
+
+
+The first step in designing of a Plan (attack scenario) is creating a Template. In this step the user is supposed to write the whole scenario in the form of Plan, Stages and Steps. An abstract Plan can look like this:
+
+```
+Plan
+ Stage 1
+ Step 1
+ Step 2
+ Stage 2
+ Step 3
+```
diff --git a/docs/contribution-guide.md b/docs/contribution-guide.md
index 5389d9dd753b4e53f00d96addddcf26ea52c377e..5324ef417778c6f5e54453a44c94445e141d44dc 100644
--- a/docs/contribution-guide.md
+++ b/docs/contribution-guide.md
@@ -1,3 +1,7 @@
## Fixing and reporting bugs
Any identified bugs should be posted as an issue in the respective [gitlab repository](https://gitlab.ics.muni.cz/cryton).
Please, include as much detail as possible for the developers, to be able to reproduce the erroneous behavior.
+
+## Writing Attack modules
+To make attack scenario automation easier we need to create and maintain attack modules. To support project development
+checkout section [How to create Attack module](2021.2.1/howto-create-attack-modules.md).
diff --git a/mkdocs.yml b/mkdocs.yml
index 96085101c3b7363305422ef117dff7619ae07e78..02cc1a032b09ac0513bc05c2955115871775cae6 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -14,41 +14,45 @@ extra:
nav:
- Home: index.md
- - Architecture: 2020.4.1/architecture.md
- - Installation:
- - Requirements: 2020.4.1/installation.md
- - Core: 2020.4.1/install-core.md
- - Worker: 2020.4.1/install-worker.md
- - Modules: 2020.4.1/install-modules.md
- - CLI: 2020.4.1/install-cli.md
- - Attack scenario:
- - About: 2020.4.1/scenario.md
- - Plan: 2020.4.1/plan.md
- - Stage: 2020.4.1/stage.md
- - Step: 2020.4.1/step.md
- - Execution variables: 2020.4.1/exec-vars.md
- - Session management: 2020.4.1/session-mngmt.md
- - Executions:
- - Execution: 2020.4.1/execution.md
- - PlanExecution: 2020.4.1/plan-execution.md
- - StageExecution: 2020.4.1/stage-execution.md
- - StepExecution: 2020.4.1/step-execution.md
- - Lifecycle: 2020.4.1/lifecycle.md
- - Attack modules:
- - About: 2020.4.1/attack-modules.md
- - mod_test: 2020.4.1/modules/mod_test.md
- - mod_cmd: 2020.4.1/modules/mod_cmd.md
- - mod_hydra: 2020.4.1/modules/mod_hydra.md
- - mod_medusa: 2020.4.1/modules/mod_medusa.md
- - mod_msf: 2020.4.1/modules/mod_msf.md
- - mod_nmap: 2020.4.1/modules/mod_nmap.md
- - mod_ssh_session: 2020.4.1/modules/mod_ssh_session.md
- - Example: 2020.4.1/example.md
+ - Installation guide:
+ - Requirements: 2021.2.1/requirements.md
+ - Core: 2021.2.1/install-core.md
+ - Worker (modules): 2021.2.1/install-worker.md
+ - CLI: 2021.2.1/install-cli.md
+ - Getting started:
+ - Tutorial 1 - Basic example: 2021.2.1/basic-example.md
+ - Tutorial 2 -Advanced example: 2021.2.1/advanced-example.md
+ - Designing phase:
+ - What is an Attack scenario: 2021.2.1/scenario.md
+ - Template:
+ - What is a Template: 2021.2.1/template.md
+ - Plan: 2021.2.1/plan.md
+ - Stage: 2021.2.1/stage.md
+ - Step: 2021.2.1/step.md
+ - Instance: 2021.2.1/instance.md
+ - Session management: 2021.2.1/session-mngmt.md
+ - Execution:
+ - Run:
+ - What is a Run: 2021.2.1/run.md
+ - Configuration: 2021.2.1/run-configuration.md
+ - Control: 2021.2.1/run-control.md
+ - Reporting: 2021.2.1/reporting.md
+ - Execution statistics: 2021.2.1/execution.md
- Interfaces:
- - Interfaces: 2020.4.1/interfaces.md
- - REST API: 2020.4.1/rest.md
- - CLI: 2020.4.1/cli.md
- - Logging: 2020.4.1/logging.md
+ - CLI: 2021.2.1/cli.md
+ - REST API: 2021.2.1/rest.md
+ - Architecture:
+ - Components: 2021.2.1/architecture.md
+ - Attack modules:
+ - What is an Attack module: 2021.2.1/attack-modules.md
+ - Modules:
+ - mod_cmd: 2021.2.1/modules/mod_cmd.md
+ - mod_medusa: 2021.2.1/modules/mod_medusa.md
+ - mod_msf: 2021.2.1/modules/mod_msf.md
+ - mod_nmap: 2021.2.1/modules/mod_nmap.md
+ - mod_ssh_session: 2021.2.1/modules/mod_ssh_session.md
+ - How to create Attack module: 2021.2.1/howto-create-attack-modules.md
+ - Logging: 2021.2.1/logging.md
- How to contribute: contribution-guide.md
- Acknowledgements: acknowledgements.md
- License: license.md