diff --git a/docs/2019.4.1/attack-modules.md b/docs/2019.4.1/attack-modules.md
deleted file mode 100644
index 0f519088d682f9391ea63026fcf82137fb024e2d..0000000000000000000000000000000000000000
--- a/docs/2019.4.1/attack-modules.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Attack modules
-
-Attack modules is a collection of Python scripts with goal of orchestrating known offensive security tools (Nmap, Metasploit, THC Hydra etc.). Although this is their intended purpose, they are still Python scripts, and therefore any custom made script can be used in similar way.
-
-Attack modules get executed inside Step objects. All provided arguments are given to the Attack module itself together with some higher level arguments (eg. Stage *target*).
-
-An exhaustive description of all available Attack modules and their input and output parameters can be seen on [Attack modules](attack-modules-documentation).
-
-## Installation
-
-To install Attack Modules as a Python package, simply run it's setup script:
-
-```
-$ python setup.py install
-```
-
-This is currently the recommended installation process, but this will change in future. Attack Modules will no longer be considered Python package and therefore only requirements (dependencies) will have to be installed to the system. The reason for this is easier updating and adding of new Modules - this way you can write your own module, copy it do specified directory, install it's dependencies and start using it.
\ No newline at end of file
diff --git a/docs/2019.4.1/example.md b/docs/2019.4.1/example.md
deleted file mode 100644
index 96458239d491ca59e1ad804534ec37b29e89af6b..0000000000000000000000000000000000000000
--- a/docs/2019.4.1/example.md
+++ /dev/null
@@ -1,90 +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 Worker**
-4. **Cryton CLI**
-
-First, 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](#running-in-apache-(WSGI)).*
-
-```
-(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.
-
-```
-
-Second step is starting a Scheduler. For this you can also use **cryton-manage** command line utility.
-
-```
-(cryton-core) root@kali:/opt/cryton# cryton-manage startscheduler
-Scheduler started
-Looking for jobs to run
-get_due_jobs for time=2020-06-10 07:09:35.131713+00:00
-Starting scheduler service. Listening on localhost:12345
-server started on [127.0.0.1]:12345
-Got []
-No jobs; waiting until a job is added
-```
-
-Last step before starting with CLI is starting the Worker on your Worker machine. Remember that the Worker must have Cryton Modules installed to be able to execute them. If you are using virtual environment, it has to be installed there.
-
-```
-(cryton-worker) vagrant@kali:~/cryton-worker$ cryton-worker
-Starting server. Listening on 0.0.0.0:50666.
-```
-
-Now we can start using CLI to control Cryton. To use CLI type **cryton-cli** in terminal in correct python enviroment.
-Localhost and port 8000 are used as default REST API address/port.
-To override it use *-H* and *-p* options.
-
-```
-(cryton-cli) root@localhost:~/cryton-cli$ cryton-cli -H 127.0.0.1 -p 8000
-```
-
-Create a Plan instance using a file containing the desired plan YAML.
-
-```
-(cryton-cli) root@localhost:~/cryton-cli$ cryton-cli plans create example-plan.yml
-Plan successfully created! ({'plan_model_id': 1, 'link': 'http://127.0.0.1:8000/cryton/api/v1/plans/1/'}).
-```
-
-To create a Plan instance using template and variables file simply specify `-i` parameter (`-i hosts-file`).
-
-To be able to execute Plans (Runs) we have to define Worker.
-
-```
-(cryton-cli) root@localhost:~/cryton-cli$ cryton-cli workers create 127.0.0.1 50666
-Worker successfully created! ({'url': 'http://127.0.0.1:8000/cryton/api/v1/workers/1/', 'id': 1, 'name': '127.0.0.1:50666', 'address': '127.0.0.1', 'port': '50666', 'state': 'DOWN'}).
-```
-
-Create a Run by choosing Plan Instance and providing list of Workers for execution.
-
-```
-(cryton-cli) root@localhost:~/cryton-cli$ 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/'}).
-```
-
-Execute created Run to start the execution tree.
-
-```
-(cryton-cli) root@localhost:~/cryton-cli$ cryton-cli runs execute 1
-Run successfully executed! (Run 1 was executed.).
-```
-
-Anytime during running of cryton the output file 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) root@localhost:~/cryton-cli$ 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)
-```
-
-#
\ No newline at end of file
diff --git a/docs/2019.4.1/images/lifecycle.png b/docs/2019.4.1/images/lifecycle.png
deleted file mode 100644
index ffcd6ee3f92b3a4a8d47821ce686860b452570b0..0000000000000000000000000000000000000000
Binary files a/docs/2019.4.1/images/lifecycle.png and /dev/null differ
diff --git a/docs/2019.4.1/images/micro-cryton.png b/docs/2019.4.1/images/micro-cryton.png
deleted file mode 100644
index a10de8b5e9d87c51a489ffb9ff183cdba28ff9b0..0000000000000000000000000000000000000000
Binary files a/docs/2019.4.1/images/micro-cryton.png and /dev/null differ
diff --git a/docs/2019.4.1/installation.md b/docs/2019.4.1/installation.md
deleted file mode 100644
index ba87fb0cef4237f09b8ac5db5a1aa930164cfbe4..0000000000000000000000000000000000000000
--- a/docs/2019.4.1/installation.md
+++ /dev/null
@@ -1,167 +0,0 @@
-# Requirements
-
-Requirements depend on the way you want to deploy Cryton. If docker-compose is used, then only following are needed:
-
-* docker.io
-* docker-compose
-
-On the other hand, if you want to install the python modules yourself, there are some more dependencies.
-
-Cryton uses PostgreSQL as it's internal database, so this must be installed and started on your system. So far the only supported OS is Kali Linux 2019.1 (and maybe newer). Additionally there are some other dependencies. Please check you have following tools/packages installed:
-
-* **Core**
- * python3.7
- * (optional) pipenv
- * postgresql
- * libpq5
- * libpq-dev
-* **Worker**
- * python3.7
- * metastploit-framework
-* **Modules**
- * python3.7
-
-Besides these dependencies there are also other python packages installed during setup.py install process.
-
-Please note that without metasploit framework, it is not possible to use session management capabilities (using and creating sessions) and metasploit related modules (mod_msf).
-
-## Installation guides
-
-### Core Installation
-
-#### docker-compose installation (recommended)
-
-First make sure you have Docker 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
-~~~~
-
-Now, run docker-compose, which will pull, build and start all necessary docker images:
-
-~~~~
-user@localhost:~ $ cd cryton-core/
-user@localhost:~ /cryton-core $ docker-compose up -d
-~~~~
-
-This process might take a while, especially if it is the first time you run it - Cryton 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:
-
-~~~~
-user@localhost:~ /cryton-core $ curl localhost:8000
-{"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/"}
-~~~~
-
-
-##### Production
-
-For production environment, there are some other options needed (such as publishing ports to public IP addressuse, persistent database data volume etc. For production deployment, use:
-
-~~~~
-user@localhost:~ /cryton-core $ docker-compose -f docker-compose.prod.yml up -d
-~~~~
-
-The rest of the steps is the same as above.
-
-
-#### Manual installation
-
-Important note: this guide only explains how to install **Cryton core** package. For being able to execute the attack scenarios, you also need to install the **Cryton worker** package. The modules you wish to execute in the attack scenarios
-
-First you need to create database and database tables Cryton internal storage. This database is also used for scheduler and tasks persistence:
-
-~~~~
-user@localhost:~ $ sudo su postgres
-postgres@localhost:~ $ psql -c "CREATE DATABASE cryton;"
-postgres@localhost:~ $ 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;";
-postgres@localhost:~ $ exit
-~~~~
-
-
-For **development** please clone respective git repositories and install them using setuptools. You can use pipenv for creating virtual environment. Then create a configuration directory in /etc/cryton and copy the configuration files. Also edit them according to your preferences.
-
-
-First, obtain the source:
-
-```
-user@localhost:~ $ git clone <cryton-repo>; cd cryton-oop
-```
-
-Then create the virtual environment using Pipenv:
-
-```
-user@localhost:~/cryton-oop$ pipenv shell # has to be virtual environment with python3.7
-```
-
-Use setup.py to install the package. Use _develop_ instead of _install_ if you wish to directly (locally) modify the code:
-
-```
-(cryton-oop) user@localhost:~/cryton-oop$ python setup.py install
-```
-
-**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.**
-
-After successful installation the only thing needed is Django _migration_ for creating default tables in Cryton database:
-
-```
-(cryton-oop) user@localhost:~/cryton-oop$ cryton-manage makemigrations cryton_rest_api
-(cryton-oop) user@localhost:~/cryton-oop$ cryton-manage migrate
-```
-
-To check if installation was successfull try to open the tools help:
-
-```
-(cryton-oop) user@localhost:~/cryton-oop$ cryton -h # installation succesfull
-```
-
-### Worker Installation
-
-For manual installation all you need is to run the setup script. You can also install this inside a virtual environment using pipenv.
-
-```
-$ python3 setup.py install
-```
-
-### Modules Installation
-
-Same installation process as for Worker:
-
-```
-$ python3 setup.py install
-```
-
-### CLI Installation
-
-Same installation process as for Worker:
-
-```
-$ python3 setup.py install
-```
-
-#
\ No newline at end of file
diff --git a/docs/2019.4.1/scenario.md b/docs/2019.4.1/scenario.md
deleted file mode 100644
index 06679bb855fd6d052ed9a85e3fab8aa7154db95f..0000000000000000000000000000000000000000
--- a/docs/2019.4.1/scenario.md
+++ /dev/null
@@ -1,171 +0,0 @@
-# Attack scenario
-
-Let's start with description of the attack scenario. I use attack scenario and Plan interchangeably - Plan is just the name of element in formal description of attack scenario.
-
-An attack scenario is a sequence of steps with some common objective. This objective may be data exfiltration, access to target systems, denial of service or any other harmful action. For the purpose of some exercises every attack should be divisible into different stages. Imagine you have to attack an infrastructure with multiple machines - each machine can be a separate stage. Or you want to attack according to some killchain, eg. first stage would be scanning of the infrastructure, second is brute force attack on credentials to found systems etc.
-
-The last and most important element of Plan description is attack step. This is the execution of attack script or tool against the target. Step can be running a metasploit exploit, or running nmap scan. Steps are dependent on each other, and so they create en execution tree, where each of them have set the list of successors based on some condition. The condition may be a success or a string value returned by it's predecessor.
-
-Putting this all together you get the whole attack scenario (called **Plan**), which is divided into different stages (called **Stage**). Every stage is set to run on specific time, as this is often required by exercise. And finally each stage consists of attack steps (called **Step**), which are organized in a non binary tree described above.
-
-You can find detailed swagger generated documentation with all parameters in [swagger](swagger) or the actual swagger documentation when running Cryton REST API. Just browse to ```/doc``` endpoint. Following sections only provide descriptions of functionalities you can utilize for Attack scenario execution.
-
-
-## Step
-
-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
-
-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
-
- Which value you want to compare, according to output of the parent Step. ('state', 'result', 'std_out' or 'std_err', 'any')
-
- * **state**: SUCCESS, FAILURE
- * **results**: OK, FAIL, EXCEPTION
- * **std_out**: String that can be found in step's std_out (or regex in form ```r<string>```)
- * **std_err**: Same principle as std_out
- * **mod_out**: Same principle as std_out
- * **mod_err**: Same principle as std_out
- * **any**: There is no need to select a specific value, because any step's result will be taken as valid.
-
-* ##### value
-
- The desired value of the selected type. Can be defined as string (one value) or list of strings (multiple values).
-
-* ##### step
-
- Name of the Step's successor(s).
- Can be string (one successor) or list of strings (multiple successors).
-
-### 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.
-
-### Executor
-
-
-### Example
-
-```yaml
-- 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: get-passwd
- is_init: true
- attack_module: misc/mod_cmd
- attack_module_args:
- cmd: cat /etc/passwd
- use_any_session_to_target: 192.168.56.103
-```
-
-## Stage
-
-Stage is a unit defined by a target and a time of start. It contains a list of attack Steps.
-
-### Target
-
-
-Target of the stage. It can be any string or variable from inventory file. Every step in the stage sends this variable to attack module as `target`, so it can be used inside.
-
-
-### Triggering
-
-#### trigger_type
-
-A type of trigger to be used. Available triggers are:
-
-* **delta**: Schedule execution for specific time after plan start, eg. `minutes: 30`
-* **HTTPListener**: 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
- target: 127.0.0.1
- 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
-```
-
-## Plan
-
-Plan is the basic unit of attack scenario. It contains name and owner of the Plan and a list of Stages.
-
-### Example
-
-```yaml
----
-plan:
- name: Example scenario
- owner: your name
- stages:
- - name: stage-one
- target: 127.0.0.1
- 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
-```
-
-## 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/2019.4.1/architecture.md b/docs/2020.4.1/architecture.md
similarity index 65%
rename from docs/2019.4.1/architecture.md
rename to docs/2020.4.1/architecture.md
index 5b70791aa003d347be6a07a5d3364f8fc6669a0c..c2469475962a48e6c023e3e5c01acc41cee3bad5 100644
--- a/docs/2019.4.1/architecture.md
+++ b/docs/2020.4.1/architecture.md
@@ -8,15 +8,13 @@ As the name suggests, this is the **Core** component of Cryton toolset. It provi
For issuing commands to Core, **REST API** is provided. This is utilized by **CLI** for normal user interactions.
-<!---->
-
## Worker
-Cryton worker is a component for executing Cryton attack modules remotely. Cryton worker utilizes gRCP with google protocol buffers (https://grpc.io/) as it's remote procedures call protocol. It listens on TCP port and receives remote procedure calls from Core component. After completing the execution of Attack Module it returns it's return value in a specific format.
+Cryton worker is a component for executing Cryton attack modules remotely. Cryton worker utilizes Rabbit MQ as it's asynchronous remote procedures call protocol. It connects to Rabbit MQ server and consumes messages from Core component. After completing the execution of Attack Module it returns it's return value in a specific format to queue specified by Core request.
## Modules
-Cryton modules component contains attack modules used by Cryton Worker. It's usage is described further in the documentation.
+Cryton modules component contains attack modules used by Cryton Worker. It's usage is described further in the documentation.
## Scheduler
diff --git a/docs/2020.4.1/attack-modules.md b/docs/2020.4.1/attack-modules.md
new file mode 100644
index 0000000000000000000000000000000000000000..117ffc29f102b7e9d3ed29e03655c16d09e3d86d
--- /dev/null
+++ b/docs/2020.4.1/attack-modules.md
@@ -0,0 +1,37 @@
+# Attack modules
+
+Attack modules is a collection of Python scripts with goal of orchestrating known offensive security tools (Nmap, Metasploit, THC Hydra etc.). Although this is their intended purpose, they are still Python scripts, and therefore any custom made script can be used in similar way.
+
+Attack modules get executed inside Step objects. All provided arguments are given to the Attack module in a form of python dictionary (equivalent to JSON format).
+
+## Input parameters
+
+Every attack module has its input parameters specified. You can find the documentation of each available module.
+These input parameters are given as a dictionary to the module ```execute``` function.
+
+## Output parameters
+
+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```. |
+| `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`. |
+
+
+
+## Example
+
+```python
+>>> import mod_test
+>>> ret = mod_test.execute({'first': 1, 'second':2})
+>>> print("return code: {}".format(ret.get('return_code')))
+return_code: 0
+>>> print("mod_out: {}".format(ret.get('mod_out')))
+mod_out: {'username': 'admin', 'passwod': 'admin'}
+```
+
diff --git a/docs/2019.4.1/interfaces.md b/docs/2020.4.1/cli.md
similarity index 57%
rename from docs/2019.4.1/interfaces.md
rename to docs/2020.4.1/cli.md
index a61b5de3779c91a0ee8a2ed1a5ca7fdd3f8555fb..7cecf9e46a8be00626454dbe8970bf053bf61360 100644
--- a/docs/2019.4.1/interfaces.md
+++ b/docs/2020.4.1/cli.md
@@ -1,75 +1,3 @@
-# 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.
-
-```
-
-### 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/cryton-oop-_aTpEfuL python-path=/root/.local/share/virtualenvs/cryton-oop-_aTpEfuL/lib/python3.7/site-packages/cryton-1.0-py3.7.egg/cryton
-WSGIProcessGroup cryton
-WSGIScriptAlias /cryton /root/.local/share/virtualenvs/cryton-oop-_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/cryton-oop-_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/cryton-oop-_aTpEfuL/python3.7/site-packages/drf_yasg/static
-
- <Directory /root/.local/share/virtualenvs/cryton-oop-_aTpEfuL/lib/python3.7/site-packages/cryton-1.0-py3.7.egg/cryton/>
- Require all granted
- </Directory>
- <Directory /root/.local/share/virtualenvs/cryton-oop-_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
-```
-
-For more information about running in Apache with mod_wsgi see https://docs.djangoproject.com/en/2.2/howto/deployment/wsgi/modwsgi/
-
-### 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
CLI implements capabilities of Cryton's REST API and can be automated by using custom scripts.
@@ -77,7 +5,6 @@ CLI implements capabilities of Cryton's REST API and can be automated by using c
To start the CLI just type in `cryton-cli`:
```
-(cryton-cli) root@localhost:~/cryton-cli$ cryton-cli
Usage: cryton-cli [OPTIONS] COMMAND [ARGS]...
A CLI wrapper for Cryton API.
@@ -89,26 +16,29 @@ Usage: cryton-cli [OPTIONS] COMMAND [ARGS]...
infrastructure.
Options:
- -H, --host TEXT Set Cryton's address (default is localhost).
- -p, --port INTEGER Set Cryton's address (default is 8000).
- --secure / --not-secure Set if HTTPS will be used (default is False).
- --version Show the version and exit.
- --help Show this message and exit.
+ -H, --host TEXT Set Cryton's address (default is localhost).
+ -p, --port INTEGER Set Cryton's address (default is 8000).
+ --secure Set if HTTPS will be used.
+ --debug Show non formatted output.
+ --version Show the version and exit.
+ --help Show this message and exit.
Commands:
- plan-executions Manage Plan's executions from here.
- plans Manage Plans from here.
- runs Manage Runs from here.
- shell Manage Shell from here.
- stage-executions Manage Stage's executions from here.
- stages Manage Stages from here.
- step-executions Manage Step's executions from here.
- steps Manage Steps from here.
- workers Manage Workers from here.
+ execution-variables Manage Execution variables from here.
+ plan-executions Manage Plan's executions from here.
+ plan-templates Manage Plan templates from here.
+ plans Manage Plans from here.
+ runs Manage Runs from here.
+ shell Manage Shell from here.
+ stage-executions Manage Stage's executions from here.
+ stages Manage Stages from here.
+ step-executions Manage Step's executions from here.
+ steps Manage Steps from here.
+ workers Manage Workers from here.
```
The default Cryton's REST API address and port are **localhost** and **8000**. To override this use `-H` and `-p` options.
-Optionally use `--secure` flag to use *HTTPS* protocol.
+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 ...
@@ -116,15 +46,46 @@ Optionally use `--secure` flag to use *HTTPS* protocol.
To show help at any point use `--help` option. For example: `cryton-cli plans list --help`.
-**workers**
+### execution-variables
+
+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 `FILE` - Path to file containing execution variables.
+
+`delete` Delete Execution variable with EXECUTION_VARIABLE_ID saved in Cryton.
+Example: `cryton-cli execution-variables delete 1`
+
+- argument `EXECUTION_VARIABLE_ID` - ID of the Execution_variable you want to delete.
+
+`list` List existing Execution variables in Cryton.
+Example: `cryton-cli execution-variables list`
+
+- option `--less` - Show less like output.
+- 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.
+
+`show` Show Execution variable with EXECUTION_VARIABLE_ID saved in Cryton.
+Example: `cryton-cli execution-variables show 1`
+
+- argument `EXECUTION_VARIABLE_ID` - ID of the desired execution variable.
+- option `--less` - Show less like output.
+- option `--localize` - Convert UTC datetime to local timezone.
+
+### workers
+
Manage Workers from here.
`create` Create new Worker with ADDRESS and PORT and save it into Cryton.
-Example: `cryton-cli workers create -n worker localhost 50666`
+Example: `cryton-cli workers create -p customPrefix localhost customName`
- argument `ADDRESS` - Address of your new Worker.
-- argument `PORT` - Port of your new Worker.
-- option `--name` - Custom name for your Worker.
+- argument `NAME` - Name of your new Worker.
+- option `--prefix` - Custom prefix for your Worker.
`delete` Delete Worker with WORKER_ID saved in Cryton.
Example: `cryton-cli workers delete 1`
@@ -135,13 +96,24 @@ Example: `cryton-cli workers delete 1`
Example: `cryton-cli workers list`
- option `--less` - Show less like output.
+- 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.
`show` Show Worker with WORKER_ID saved in Cryton.
Example: `cryton-cli workers show 1`
- argument `WORKER_ID` - ID of the Worker you want to show.
+- option `--less` - Show less like output.
+- option `--localize` - Convert UTC datetime to local timezone.
+
+`health-check` Check if Worker with WORKER_ID saved in Cryton is online.
+Example: `cryton-cli workers health-check 1`
+
+- argument `WORKER_ID` - ID of the Worker you want to check.
+
+### runs
-**runs**
Manage Runs from here.
`create` Create new Run with PLAN_ID and WORKERS list.
@@ -164,6 +136,9 @@ Example: `cryton-cli runs execute 1`
Example: `cryton-cli runs list`
- option `--less` - Show less like output.
+- 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.
`pause` Pause Run saved in Cryton with RUN_ID.
Example: `cryton-cli runs pause 1`
@@ -183,6 +158,7 @@ Example: `cryton-cli runs report 1 -f /path/to/directory`
- argument `RUN_ID` - ID of the Run you want to report.
- option `--file` - File to save the report to (default is `/tmp`).
+- option `--less` - Show less like output.
`reschedule` Reschedule Run saved in Cryton with RUN_ID to specified DATE and TIME.
Example: `cryton-cli runs reschedule 1 2020-06-08 10:00:00`
@@ -190,6 +166,7 @@ Example: `cryton-cli runs reschedule 1 2020-06-08 10:00:00`
- argument `RUN_ID` - ID of the Run you want to reschedule.
- argument `DATE` - Date in format year-month-day.
- argument `TIME` - Time in format hours:minutes:seconds.
+- option `--utc-timezone` - Use UTC timezone instead of local timezone.
`resume` Resume Run saved in Cryton with RUN_ID.
Example: `cryton-cli runs resume 1`
@@ -202,11 +179,14 @@ Example: `cryton-cli runs schedule 1 2020-06-08 10:00:00`
- argument `RUN_ID` - ID of the Run you want to schedule.
- argument `DATE` - Date in format year-month-day.
- argument `TIME` - Time in format hours:minutes:seconds.
+- option `--utc-timezone` - Use UTC timezone instead of local timezone.
`show` Show Run with RUN_ID saved in Cryton.
Example: `cryton-cli runs show 1`
- argument `RUN_ID` - ID of the Run you want to show.
+- option `--less` - Show less like output.
+- option `--localize` - Convert UTC datetime to local timezone.
`unschedule` Unschedule Run saved in Cryton with RUN_ID.
Example: `cryton-cli runs unschedule 1`
@@ -214,26 +194,49 @@ Example: `cryton-cli runs unschedule 1`
- argument `RUN_ID` - ID of the Run you want to unschedule.
-**plan-executions**
+### plan-executions
+
Manage Plan's executions from here.
`list` List existing Plan's executions in Cryton.
Example: `cryton-cli plan-executions list`
- option `--less` - Show less like output.
+- 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.
`report` Create report for Plan's execution with EXECUTION_ID saved in Cryton.
Example: `cryton-cli plan-executions report 1 -f /path/to/directory`
- argument `EXECUTION_ID` - ID of the Plan's execution you want to report.
- option `--file` - File to save the report to (default is `/tmp`).
+- option `--less` - Show less like output.
`show` Show Plan's execution with EXECUTION_ID saved in Cryton.
Example: `cryton-cli plan-executions show 1`
- argument `EXECUTION_ID` - ID of the Plan's execution you want to show.
+- option `--less` - Show less like output.
+- option `--localize` - Convert UTC datetime to local timezone.
+
+`pause` Pause Plan's execution with EXECUTION_ID saved in Cryton.
+Example: `cryton-cli plan-executions pause 1`
+
+- argument `EXECUTION_ID` - ID of the Plan's execution you want to pause.
+
+`resume` Resume Plan's execution with EXECUTION_ID saved in Cryton.
+Example: `cryton-cli plan-executions resume 1`
+
+- argument `EXECUTION_ID` - ID of the Plan's execution you want to resume.
+
+`validate-modules` Validate modules for Plan's execution with EXECUTION_ID saved in Cryton.
+Example: `cryton-cli plan-executions validate-modules 1`
+
+- argument `EXECUTION_ID` - ID of the Plan's execution you want to validate modules for.
+
+### plans
-**plans**
Manage Plans from here.
`create` Validate and save your FILE with Plan into Cryton.
@@ -258,11 +261,16 @@ Example: `cryton-cli plans execute 1`
Example: `cryton-cli plans list`
- option `--less` - Show less like output.
+- 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.
`show` Show Plan with PLAN_ID saved in Cryton.
Example: `cryton-cli plans show 1`
- argument `PLAN_ID` - ID of the Plan you want to show.
+- option `--less` - Show less like output.
+- option `--localize` - Convert UTC datetime to local timezone.
`validate` Validate (syntax check) your FILE with Plan.
Example: `cryton-cli plans validate -i path/to/variables path/to/template`
@@ -270,26 +278,34 @@ Example: `cryton-cli plans validate -i path/to/variables path/to/template`
- argument `FILE` - path/to/your/file that you want to validate.
- option `--inventory` - Path to an inventory file containing variables.
-**stage-executions**
+### stage-executions
+
Manage Stage's executions from here.
`list` List existing Stage's executions in Cryton.
Example: `cryton-cli stage-executions list`
- option `--less` - Show less like output.
+- 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.
`report` Create report for Stage's execution with EXECUTION_ID saved in Cryton.
Example: `cryton-cli stage-executions report 1 -f /path/to/directory`
- argument `EXECUTION_ID` - ID of the Stage's execution you want to report.
- option `--file` - File to save the report to (default is `/tmp`).
+- option `--less` - Show less like output.
`show` Show Stage's execution with EXECUTION_ID saved in Cryton.
Example: `cryton-cli stage-executions show 1`
- argument `EXECUTION_ID` - ID of the Stage's execution you want to show.
+- option `--less` - Show less like output.
+- option `--localize` - Convert UTC datetime to local timezone.
+
+### stages
-**stages**
Manage Stages from here.
`create` Validate and save your FILE with Stage into Cryton.
@@ -314,11 +330,16 @@ Example: `cryton-cli stages execute 1`
Example: `cryton-cli stages list`
- option `--less` - Show less like output.
+- 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.
`show` Show Stage with STAGE_ID saved in Cryton.
Example: `cryton-cli stages show 1`
- argument `STAGE_ID` - ID of the Stage you want to show.
+- option `--less` - Show less like output.
+- option `--localize` - Convert UTC datetime to local timezone.
`validate` Validate (syntax check) your FILE with Stage.
Example: `cryton-cli stages validate -i path/to/variables path/to/template`
@@ -326,26 +347,34 @@ Example: `cryton-cli stages validate -i path/to/variables path/to/template`
- argument `FILE` - path/to/your/file that you want to validate.
- option `--inventory` - Path to an inventory file containing variables.
-**step-executions**
+### step-executions
+
Manage Step's executions from here.
`list` List existing Step's executions in Cryton.
Example: `cryton-cli step-executions list`
- option `--less` - Show less like output.
+- 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.
`report` Create report for Step's execution with EXECUTION_ID saved in Cryton.
Example: `cryton-cli step-executions report 1 -f /path/to/directory`
- argument `EXECUTION_ID` - ID of the Step's execution you want to report.
- option `--file` - File to save the report to (default is `/tmp`).
+- option `--less` - Show less like output.
`show` Show Step's execution with EXECUTION_ID saved in Cryton.
Example: `cryton-cli step-executions show 1`
- argument `EXECUTION_ID` - ID of the Step's execution you want to show.
+- option `--less` - Show less like output.
+- option `--localize` - Convert UTC datetime to local timezone.
+
+### steps
-**steps**
Manage Steps from here.
`create` Validate and save your FILE with Step into Cryton.
@@ -370,11 +399,16 @@ Example: `cryton-cli steps execute 1`
Example: `cryton-cli steps list`
- option `--less` - Show less like output.
+- 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.
`show` Show Step with STEP_ID saved in Cryton.
Example: `cryton-cli steps show 1`
- argument `STEP_ID` - ID of the Step you want to show.
+- option `--less` - Show less like output.
+- option `--localize` - Convert UTC datetime to local timezone.
`validate` Validate (syntax check) your FILE with Step.
Example: `cryton-cli steps validate -i path/to/variables path/to/template`
@@ -382,112 +416,10 @@ Example: `cryton-cli steps validate -i path/to/variables path/to/template`
- argument `FILE` - path/to/your/file that you want to validate.
- option `--inventory` - Path to an inventory file containing variables.
-**shell**
+### shell
+
Manage Shell from here.
+**!Shell is currently unavailable!**
`start` Start an interactive shell.
-Example: `cryton-cli shell start`
-
-## Shell
-
-Shell works the same as CLI. However it is designed to be interactive and more user friendly.
-
-Default Cryton's REST API address and port are inherited from CLI. Use CLI options to change them:
-
-```
-(cryton-cli) root@localhost:~/cryton-cli$ cryton-cli -H 127.0.0.1 -p 8000 shell start
-```
-
-To start Shell use CLI.
-
-```
-(cryton-cli) root@localhost:~/cryton-cli$ cryton-cli shell start
-Welcome to Cryton's interactive console! Type help or press 'tab' twice.
-Cryton >
-```
-
-To show help at any point use `help <command>`. For example: `Cryton > help` or `Cryton > help plans`.
-
-List of available commands and their sub commands:
-
-**workers**
-Manage Workers from here.
-
-`workers list` - prints all Workers
-`workers show <ID>` - prints Worker with specified ID
-`workers delete <ID>` - deletes Worker with specified ID
-`workers create <ADDRESS> <PORT> <NAME>` - creates new worker ADDRESS:PORT and optionally a custom name
-
-**runs**
-Manage Runs from here.
-
-`runs list` - prints all Runs
-`runs create <PLAN MODEL ID> [WORKER IDs]` - creates new Run with specified MODEL and WORKERS
-`runs show <ID>` - prints Run with specified ID
-`runs delete <ID>` - deletes Run with specified ID
-`runs switch <ID>` - Switches to Run context with specified ID
-
-**plan-executions**
-Manage Plan's executions from here.
-
-`plan_executions list` - prints all Plan-executions
-`plan_executions show <ID>` - prints Plan-execution with specified ID
-`plan_executions report <ID>` - Creates report for Plan-execution with specified ID
-
-**plans**
-Manage Plans from here.
-
-`plans list` - prints all Plans
-`plans show <ID>` - prints Plan with specified ID
-`plans delete <ID>` - deletes Plan with specified ID
-`plans execute <ID> <Run ID> <Worker ID>` - executes Plan with specified <ID> in Run with <Run ID> on worker with <Worker ID>
-
-**stage-executions**
-Manage Stage's executions from here.
-
-`stage_executions list` - prints all Stage-executions
-`stage_executions show <ID>` - prints Stage-execution with specified ID
-`stage_executions report <ID>` - Creates report for Stage-execution with specified ID
-
-**stages**
-Manage Stages from here.
-
-`stages list` - prints all Stages
-`stages show <ID>` - prints Stage with specified ID
-`stages delete <ID>` - deletes Stage with specified ID
-`stages execute <ID> <PlanExecution ID>` - executes Stage with specified <ID> and attach it to Plan's execution with <PlanExecution ID>
-
-**step-executions**
-Manage Step's executions from here.
-
-`step_executions list` - prints all Step-executions
-`step_executions show <ID>` - prints Step-execution with specified ID
-`step_executions report <ID>` - Creates report for Step-execution with specified ID
-
-**steps**
-Manage Steps from here.
-
-`steps list` - prints all Steps
-`steps show <ID>` - prints Step with specified ID
-`steps delete <ID>` - deletes Step with specified ID
-`steps execute <ID> <StageExecution ID>` - executes Step with specified <ID> and attach it to Stage's execution with <StageExecution ID>
-
-For better control over *Runs* you can switch to Run context.
-
-```
-Cryton > runs switch <ID>
-```
-
-And exit it with `CTRL+d` or type in `exit`.
-
-All previously mentioned commands are available + there are some additional for better user experience.
-
-`show` Shows current Run. Example: `show`
-`execute` Executes current Run. Example: `execute`
-`pause` Pauses current Run. Example: `pause`
-`postpone` Postpones current Run by HOURS, MINUTES and SECONDS. Example: `postpone 0 0 5`
-`report` Reports current Run. Example: `report`
-`reschedule` Reschedules current Run. Example: `reschedule 2020-05-31 19:00:00`
-`schedule` Schedules current Run. Example: `schedule 2020-05-31 19:00:00`
-`resume` Resumes current Run. Example: `resume`
-`unschedule` Unschedules current Run. Example: `unschedule`
\ No newline at end of file
+Example: `cryton-cli shell start`
\ No newline at end of file
diff --git a/docs/2020.4.1/example.md b/docs/2020.4.1/example.md
new file mode 100644
index 0000000000000000000000000000000000000000..46a140591df363bae1deef6eb7af0cb5c40d9260
--- /dev/null
+++ b/docs/2020.4.1/example.md
@@ -0,0 +1,216 @@
+# 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/exec-vars.md b/docs/2020.4.1/exec-vars.md
new file mode 100644
index 0000000000000000000000000000000000000000..dece477972e8c555513f5144b7342ffaa1f88ca2
--- /dev/null
+++ b/docs/2020.4.1/exec-vars.md
@@ -0,0 +1,20 @@
+### 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](interfaces.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/2020.4.1/execution.md b/docs/2020.4.1/execution.md
new file mode 100644
index 0000000000000000000000000000000000000000..53669de12e3bfd70f2c1d527085c79541ad7e913
--- /dev/null
+++ b/docs/2020.4.1/execution.md
@@ -0,0 +1,11 @@
+## 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/2019.4.1/images/architecture.png b/docs/2020.4.1/images/architecture.png
similarity index 100%
rename from docs/2019.4.1/images/architecture.png
rename to docs/2020.4.1/images/architecture.png
diff --git a/docs/2019.4.1/images/core-component.png b/docs/2020.4.1/images/core-component.png
similarity index 100%
rename from docs/2019.4.1/images/core-component.png
rename to docs/2020.4.1/images/core-component.png
diff --git a/docs/2019.4.1/images/flow-diagram.png b/docs/2020.4.1/images/flow-diagram.png
similarity index 100%
rename from docs/2019.4.1/images/flow-diagram.png
rename to docs/2020.4.1/images/flow-diagram.png
diff --git a/docs/2020.4.1/images/lifecycle.png b/docs/2020.4.1/images/lifecycle.png
new file mode 100644
index 0000000000000000000000000000000000000000..c283a37b438e6eb48a41ba39f4ac0cfe225f6070
Binary files /dev/null and b/docs/2020.4.1/images/lifecycle.png differ
diff --git a/docs/2020.4.1/images/micro-cryton.png b/docs/2020.4.1/images/micro-cryton.png
new file mode 100644
index 0000000000000000000000000000000000000000..efb820f456580026c5e46224a9d0ab5f65790694
Binary files /dev/null and b/docs/2020.4.1/images/micro-cryton.png differ
diff --git a/docs/2019.4.1/images/modules-component.png b/docs/2020.4.1/images/modules-component.png
similarity index 100%
rename from docs/2019.4.1/images/modules-component.png
rename to docs/2020.4.1/images/modules-component.png
diff --git a/docs/2019.4.1/images/templates.png b/docs/2020.4.1/images/templates.png
similarity index 100%
rename from docs/2019.4.1/images/templates.png
rename to docs/2020.4.1/images/templates.png
diff --git a/docs/2019.4.1/images/worker-component.png b/docs/2020.4.1/images/worker-component.png
similarity index 100%
rename from docs/2019.4.1/images/worker-component.png
rename to docs/2020.4.1/images/worker-component.png
diff --git a/docs/2020.4.1/install-cli.md b/docs/2020.4.1/install-cli.md
new file mode 100644
index 0000000000000000000000000000000000000000..5e78699a1784fb11a7d47574c1124e203ce2e14e
--- /dev/null
+++ b/docs/2020.4.1/install-cli.md
@@ -0,0 +1,58 @@
+## CLI Installation
+
+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_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
+CRYTON_CLI_API_ROOT_URL=cryton/api/v1/
+~~~~
+
+#### Requirements
+
+- python3.8 (tested version)
+- pipenv (optional)
+
+#### Installation
+
+Go into Cryton CLI directory, create python environment, enter it and install CLI.
+
+~~~~
+cd cryton-cli
+pipenv install
+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:
+
+~~~~
+cryton-cli
+~~~~
+
+You should see something like:
+
+~~~~
+Usage: cryton-cli [OPTIONS] COMMAND [ARGS]...
+
+ A CLI wrapper for Cryton API.
+
+ This research was supported by the Security Research Programme of the
+ Czech Republic 2015-2020 (BV III/1 – VS) granted by the Ministry of the
+ Interior of the Czech Republic under No. VI20162019014 – Simulation,
+ detection, and mitigation of cyber threats endangering critical
+ infrastructure.
+~~~~
+
diff --git a/docs/2020.4.1/install-core.md b/docs/2020.4.1/install-core.md
new file mode 100644
index 0000000000000000000000000000000000000000..72b6b6b8bc81de11c013c78552af8c305ea9dcc2
--- /dev/null
+++ b/docs/2020.4.1/install-core.md
@@ -0,0 +1,202 @@
+## 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
new file mode 100644
index 0000000000000000000000000000000000000000..efc0ca30cd16625b60bb431d83749bf267797dcb
--- /dev/null
+++ b/docs/2020.4.1/install-modules.md
@@ -0,0 +1,15 @@
+## 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
new file mode 100644
index 0000000000000000000000000000000000000000..ea2ac35965c99218a258c7723b739783fa163058
--- /dev/null
+++ b/docs/2020.4.1/install-worker.md
@@ -0,0 +1,134 @@
+## 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
new file mode 100644
index 0000000000000000000000000000000000000000..5348f20f86e1cc04fdf3bf8cb5f333f08ae886f1
--- /dev/null
+++ b/docs/2020.4.1/installation.md
@@ -0,0 +1,28 @@
+# 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
new file mode 100644
index 0000000000000000000000000000000000000000..8dc02afc32f489b6d5eda13d11e8c3de75875ddc
--- /dev/null
+++ b/docs/2020.4.1/interfaces.md
@@ -0,0 +1,33 @@
+# 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/2019.4.1/lifecycle.md b/docs/2020.4.1/lifecycle.md
similarity index 73%
rename from docs/2019.4.1/lifecycle.md
rename to docs/2020.4.1/lifecycle.md
index b41e2a205dcb0d1e44e960c268614d4324b1752c..2735886cf5111f76564ec7d6685893870be99a9f 100644
--- a/docs/2019.4.1/lifecycle.md
+++ b/docs/2020.4.1/lifecycle.md
@@ -1,6 +1,9 @@
# 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:
@@ -11,7 +14,6 @@ There are multiple stages which need to be followed for creating and executing t
* 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.
@@ -33,27 +35,25 @@ You can use it as in following example:
```
# Stage two: target is web server
- - name: web-server
- target: {{hosts.web_server}}
+ - name: {{names.stage1}}
```
-You can use Jinja variables everywhere in the Plan template. Only special usecase is using them in Workers specification. For every Worker variable a separate Run is created. Runs are described in other sections of the documentation.
+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**.
-### Inventory file
+**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:
```
-[hosts]
-web_server: 192.168.56.102
+[names]
+stage1: 192.168.56.102
```
## Run
-
-When you finally have an Instance stored inside database, you can create a new Run. For every execution of the Instance a new Run is created. The reason behind this is storage of execution history, so it is possible to compare different Runs results.
-
-When you use Workers in your Plan there is as separate *PlanExecution* created for each one of them, but only one Run.
\ No newline at end of file
+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/2019.4.1/logging.md b/docs/2020.4.1/logging.md
similarity index 100%
rename from docs/2019.4.1/logging.md
rename to docs/2020.4.1/logging.md
diff --git a/docs/2020.4.1/modules/mod_cmd.md b/docs/2020.4.1/modules/mod_cmd.md
new file mode 100644
index 0000000000000000000000000000000000000000..ea591164c7bc723b1e6b483a6207b960d3be3d77
--- /dev/null
+++ b/docs/2020.4.1/modules/mod_cmd.md
@@ -0,0 +1,66 @@
+# mod_cmd
+
+Module for running shell commands (depending on the shell used). When specifying "use_session" or "use_named_session", the command will be executed in the respective sessions context, eg. meterpreter.
+
+## Requirements
+
+System requirements (those not listed in requirements.txt for python).
+
+### **For use with sessions only**
+
+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 |
+| ---------------- | ---------------------- |
+| `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 |
+
+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.
+
+#### Example yaml(s)
+
+``` yaml
+attack_module_args:
+ cmd: cat /etc/passwd
+ output_file: /tmp/
+```
+
+## Output
+
+Description of output.
+
+| Parameter name | Parameter description |
+| --------------- | ------------------------------------------------------- |
+| `file_contents` | File that contains output of command in `cmd` parameter |
+
+#### Example
+
+**With `output_file` parameter:**
+
+```json
+{"mod_out": {"file_contents": "path/to/file"}}
+```
+
+**Without `output_file` parameter:**
+
+```json
+{"mod_out": {"cmd_out": "command output"}}
+```
diff --git a/docs/2020.4.1/modules/mod_hydra.md b/docs/2020.4.1/modules/mod_hydra.md
new file mode 100644
index 0000000000000000000000000000000000000000..00bf8edd2c059294280067cc7ac2edd2652edc03
--- /dev/null
+++ b/docs/2020.4.1/modules/mod_hydra.md
@@ -0,0 +1,64 @@
+# 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
new file mode 100644
index 0000000000000000000000000000000000000000..523bf2d67ca47f5b9ad7184f558e097679cae510
--- /dev/null
+++ b/docs/2020.4.1/modules/mod_medusa.md
@@ -0,0 +1,72 @@
+# 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
new file mode 100644
index 0000000000000000000000000000000000000000..7732e8ffe72eed88a6b8b25d48bceceabcea012e
--- /dev/null
+++ b/docs/2020.4.1/modules/mod_msf.md
@@ -0,0 +1,48 @@
+# 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
new file mode 100644
index 0000000000000000000000000000000000000000..afb5faf2c9cbb7773abc0c80d4f4cc49d612eec4
--- /dev/null
+++ b/docs/2020.4.1/modules/mod_nmap.md
@@ -0,0 +1,60 @@
+# 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_ssh_session.md b/docs/2020.4.1/modules/mod_ssh_session.md
new file mode 100644
index 0000000000000000000000000000000000000000..7811ca02816ad764e803dcf095f0b15f7327155f
--- /dev/null
+++ b/docs/2020.4.1/modules/mod_ssh_session.md
@@ -0,0 +1,58 @@
+# mod_ssh_session
+
+Module for creating a Metasploit session via SSH login.
+
+## 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 |
+| ----------------- | ----------------------------------------------- |
+| `username` | Username to use for ssh connection |
+| `password` | Password to use for ssh connection |
+| `host` (optional) | Remote host (default is target from step/stage) |
+| `port` (optional) | Remote port (default is 22) |
+
+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:
+ username: msfadmin
+ password: msfadmin
+ host: 127.0.0.1
+ port: 2222
+```
+
+## 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/modules/mod_test.md b/docs/2020.4.1/modules/mod_test.md
new file mode 100644
index 0000000000000000000000000000000000000000..045c8b7e8121198610cb46eaedae64da870f2d2d
--- /dev/null
+++ b/docs/2020.4.1/modules/mod_test.md
@@ -0,0 +1,28 @@
+# 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
new file mode 100644
index 0000000000000000000000000000000000000000..69eb111c21951de40bbded64417fe12d3e5a9c38
--- /dev/null
+++ b/docs/2020.4.1/plan-execution.md
@@ -0,0 +1,12 @@
+# 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/plan.md b/docs/2020.4.1/plan.md
new file mode 100644
index 0000000000000000000000000000000000000000..e7b1e230a75a2bdbff33ae76bb46b56f4492a128
--- /dev/null
+++ b/docs/2020.4.1/plan.md
@@ -0,0 +1,57 @@
+
+Plan is the basic unit of attack scenario. It contains name and owner of the Plan and a list of Stages.
+
+### Example
+
+```yaml
+---
+plan:
+ name: Example scenario
+ owner: your 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
+ open_ports: $parent.open_ports
+ username: vagrant
+ password: vagrant
+ next:
+ - type: result
+ value: OK
+ step: ssh-session
+ - name: ssh-session
+ create_named_session: session_to_target_1
+ attack_module: mod_msf
+ attack_module_args:
+ exploit: auxiliary/scanner/ssh/ssh_login
+ exploit_arguments:
+ RHOSTS: 127.0.0.1
+ USERNAME: $parent.username
+ PASSWORD: $parent.password
+ next:
+ - type: result
+ value: OK
+ step: session-cmd
+ - name: session-cmd
+ attack_module: mod_cmd
+ use_named_session: session_to_target_1
+ attack_module_args:
+ cmd: cat /etc/passwd
+```
diff --git a/docs/2020.4.1/rest.md b/docs/2020.4.1/rest.md
new file mode 100644
index 0000000000000000000000000000000000000000..6bc322df4bcf507aacf34111b8293e3fe3e9c19a
--- /dev/null
+++ b/docs/2020.4.1/rest.md
@@ -0,0 +1,1064 @@
+# Cryton REST API
+This document provides documentation of Cryton REST API endpoints. It was automatically generated from Swagger via swagger-markdown tool.
+
+If you are interested in Swagger interactive documentation, browse to `/doc` endpoint on Cryton REST API.
+
+## Version: v1
+
+**Contact information:**
+nutar@ics.muni.cz
+
+
+
+### /plan_executions/
+
+#### GET
+##### Description
+
+List available PlanExecutions
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| limit | query | Number of results to return per page. | No | integer |
+| offset | query | The initial index from which to return the results. | No | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+
+### /plan_executions/{id}/
+
+#### GET
+##### Description
+
+Get PlanExecution specified by ID
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this plan execution model. | Yes | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | [PlanExecutionModel](#planexecutionmodel) |
+
+### /plan_executions/{id}/report/
+
+#### GET
+##### Description
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this plan execution model. | Yes | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | [PlanExecutionModel](#planexecutionmodel) |
+
+### /plans/
+
+#### GET
+##### Description
+
+List available Plans
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| limit | query | Number of results to return per page. | No | integer |
+| offset | query | The initial index from which to return the results. | No | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+
+#### POST
+##### Description
+
+Create new Plan. You have to provide a whole JSON/YAML describing all Stages and Steps
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| data | body | | Yes | [PlanModelSerializerCreate](#planmodelserializercreate) |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 201 | | object |
+| 400 | | object |
+| 500 | | object |
+
+### /plans/validate/
+
+#### POST
+##### Description
+
+Validate Plan dictionary
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| data | body | | Yes | [PlanModelSerializerCreate](#planmodelserializercreate) |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+| 400 | | object |
+| 500 | | object |
+
+### /plans/{id}/
+
+#### GET
+##### Description
+
+Get Plan specified by ID
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this plan model. | Yes | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | [PlanModel](#planmodel) |
+
+#### DELETE
+##### Description
+
+Delete Plan specified by ID
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this plan model. | Yes | integer |
+
+##### Responses
+
+| Code | Description |
+| ---- | ----------- |
+| 204 | |
+
+### /plans/{id}/execute/
+
+#### POST
+##### Description
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this plan model. | Yes | integer |
+| data | body | | Yes | object |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+| 400 | | object |
+
+### /runs/
+
+#### GET
+##### Description
+
+List available Runs
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| limit | query | Number of results to return per page. | No | integer |
+| offset | query | The initial index from which to return the results. | No | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+
+#### POST
+##### Description
+
+Create new Run
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| data | body | | Yes | [RunModelSerializerCreate](#runmodelserializercreate) |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 201 | | object |
+| 400 | | object |
+
+### /runs/{id}/
+
+#### GET
+##### Description
+
+Get Run specified by ID
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this run model. | Yes | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | [RunModel](#runmodel) |
+
+#### DELETE
+##### Description
+
+Delete Run specified by ID
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this run model. | Yes | integer |
+
+##### Responses
+
+| Code | Description |
+| ---- | ----------- |
+| 204 | |
+
+### /runs/{id}/execute/
+
+#### POST
+##### Description
+
+Execute Run
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this run model. | Yes | integer |
+| data | body | | Yes | object |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+| 400 | | object |
+| 500 | | object |
+
+### /runs/{id}/pause/
+
+#### POST
+##### Description
+
+Pause Run
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this run model. | Yes | integer |
+| data | body | | Yes | object |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+| 400 | | object |
+| 500 | | object |
+
+### /runs/{id}/postpone/
+
+#### POST
+##### Description
+
+Postpone Run
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this run model. | Yes | integer |
+| data | body | | Yes | object |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+| 400 | | object |
+| 500 | | object |
+
+### /runs/{id}/report/
+
+#### GET
+##### Description
+
+Generate Run report
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this run model. | Yes | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+| 400 | | object |
+| 500 | | object |
+
+### /runs/{id}/reschedule/
+
+#### POST
+##### Description
+
+Reschedule Run
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this run model. | Yes | integer |
+| data | body | | Yes | object |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+| 400 | | object |
+| 500 | | object |
+
+### /runs/{id}/schedule/
+
+#### POST
+##### Description
+
+Schedule Run
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this run model. | Yes | integer |
+| data | body | | Yes | object |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+| 400 | | object |
+| 500 | | object |
+
+### /runs/{id}/unpause/
+
+#### POST
+##### Description
+
+Unpause Run
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this run model. | Yes | integer |
+| data | body | | Yes | object |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+| 400 | | object |
+| 500 | | object |
+
+### /runs/{id}/unschedule/
+
+#### POST
+##### Description
+
+Unschedule Run
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this run model. | Yes | integer |
+| data | body | | Yes | object |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 201 | | object |
+| 400 | | object |
+| 500 | | object |
+
+### /slaves/
+
+#### GET
+##### Description
+
+List available SlaveModels
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| limit | query | Number of results to return per page. | No | integer |
+| offset | query | The initial index from which to return the results. | No | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+
+#### POST
+##### Description
+
+Create new SlaveModel
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| data | body | | Yes | [SlaveModel](#slavemodel) |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 201 | | [SlaveModel](#slavemodel) |
+
+### /slaves/{id}/
+
+#### GET
+##### Description
+
+Get SlaveModel specified by ID
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this slave model. | Yes | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | [SlaveModel](#slavemodel) |
+
+#### DELETE
+##### Description
+
+Delete SlaveModel
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this slave model. | Yes | integer |
+
+##### Responses
+
+| Code | Description |
+| ---- | ----------- |
+| 204 | |
+
+### /stage_executions/
+
+#### GET
+##### Description
+
+List available StageExecutions
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| limit | query | Number of results to return per page. | No | integer |
+| offset | query | The initial index from which to return the results. | No | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+
+### /stage_executions/{id}/
+
+#### GET
+##### Description
+
+Get StageExecution specified by ID
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this stage execution model. | Yes | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | [StageExecutionModel](#stageexecutionmodel) |
+
+### /stage_executions/{id}/report/
+
+#### GET
+##### Description
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this stage execution model. | Yes | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | [StageExecutionModel](#stageexecutionmodel) |
+
+### /stages/
+
+#### GET
+##### Description
+
+List available Stages
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| limit | query | Number of results to return per page. | No | integer |
+| offset | query | The initial index from which to return the results. | No | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+
+#### POST
+##### Description
+
+Create new Stage.
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| data | body | | Yes | [StageModelSerializerCreate](#stagemodelserializercreate) |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 201 | | object |
+| 400 | | object |
+| 500 | | object |
+
+### /stages/validate/
+
+#### POST
+##### Description
+
+Validate Stage.
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| data | body | | Yes | [StageModelSerializerCreate](#stagemodelserializercreate) |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+| 400 | | object |
+
+### /stages/{id}/
+
+#### GET
+##### Description
+
+Get Stage specified by ID
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this stage model. | Yes | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | [StageModel](#stagemodel) |
+
+#### DELETE
+##### Description
+
+Delete Stage specified by ID
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this stage model. | Yes | integer |
+
+##### Responses
+
+| Code | Description |
+| ---- | ----------- |
+| 204 | |
+
+### /stages/{id}/execute/
+
+#### POST
+##### Description
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this stage model. | Yes | integer |
+| data | body | | Yes | object |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+| 400 | | object |
+
+### /step_executions/
+
+#### GET
+##### Description
+
+List available StepExecutions
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| limit | query | Number of results to return per page. | No | integer |
+| offset | query | The initial index from which to return the results. | No | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+
+### /step_executions/{id}/
+
+#### GET
+##### Description
+
+Get StepExecution specified by ID
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this step execution model. | Yes | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | [StepExecutionModel](#stepexecutionmodel) |
+
+### /step_executions/{id}/report/
+
+#### GET
+##### Description
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this step execution model. | Yes | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | [StepExecutionModel](#stepexecutionmodel) |
+
+### /steps/
+
+#### GET
+##### Description
+
+List available Steps
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| limit | query | Number of results to return per page. | No | integer |
+| offset | query | The initial index from which to return the results. | No | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+
+#### POST
+##### Description
+
+Create new Stage.
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| data | body | | Yes | [StepModelSerializerCreate](#stepmodelserializercreate) |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 201 | | object |
+| 400 | | object |
+
+### /steps/validate/
+
+#### POST
+##### Description
+
+Validate Step.
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| data | body | | Yes | [StepModelSerializerCreate](#stepmodelserializercreate) |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+| 400 | | object |
+
+### /steps/{id}/
+
+#### GET
+##### Description
+
+Get Step specified by ID
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this step model. | Yes | integer |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | [StepModel](#stepmodel) |
+
+#### DELETE
+##### Description
+
+Delete Step specified by ID
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this step model. | Yes | integer |
+
+##### Responses
+
+| Code | Description |
+| ---- | ----------- |
+| 204 | |
+
+### /steps/{id}/execute/
+
+#### POST
+##### Description
+
+##### Parameters
+
+| Name | Located in | Description | Required | Schema |
+| ---- | ---------- | ----------- | -------- | ---- |
+| id | path | A unique integer value identifying this step model. | Yes | integer |
+| data | body | | Yes | object |
+
+##### Responses
+
+| Code | Description | Schema |
+| ---- | ----------- | ------ |
+| 200 | | object |
+| 400 | | object |
+
+### Models
+
+#### PlanExecutionModel
+
+| Name | Type | Description | Required |
+| ---- | ---- | ----------- | -------- |
+| url | string (uri) | | No |
+| id | string | | No |
+| created_at | dateTime | | No |
+| updated_at | dateTime | | No |
+| start_time | dateTime | | No |
+| pause_time | dateTime | | No |
+| finish_time | dateTime | | No |
+| state | string | | No |
+| aps_job_id | string | | No |
+| evidence_dir | string | | No |
+| run | string (uri) | | Yes |
+| plan_model | string (uri) | | Yes |
+| slave | string (uri) | | Yes |
+
+#### PlanModel
+
+| Name | Type | Description | Required |
+| ---- | ---- | ----------- | -------- |
+| url | string (uri) | | No |
+| id | string | | No |
+| runs | [ string (uri) ] | | No |
+| stages | [ string (uri) ] | | No |
+| created_at | dateTime | | No |
+| updated_at | dateTime | | No |
+| name | string | | Yes |
+| owner | string | | No |
+| evidence_dir | string | | No |
+
+#### StepModelSerializerCreateExcl
+
+| Name | Type | Description | Required |
+| ---- | ---- | ----------- | -------- |
+| url | string (uri) | | No |
+| id | string | | No |
+| created_at | dateTime | | No |
+| updated_at | dateTime | | No |
+| name | string | | Yes |
+| attack_module | string | | Yes |
+| attack_module_args | object | | Yes |
+| is_init | boolean | | No |
+| executor | string | | No |
+| create_named_session | string | | No |
+| use_named_session | string | | No |
+| use_any_session_to_target | string | | No |
+
+#### StageModelSerializerCreateExcl
+
+| Name | Type | Description | Required |
+| ---- | ---- | ----------- | -------- |
+| url | string (uri) | | No |
+| id | string | | No |
+| steps | [ [StepModelSerializerCreateExcl](#stepmodelserializercreateexcl) ] | | Yes |
+| created_at | dateTime | | No |
+| updated_at | dateTime | | No |
+| name | string | | Yes |
+| target | string | | No |
+| executor | string | | No |
+| trigger_type | string | | Yes |
+| trigger_args | object | | Yes |
+
+#### PlanModelSerializerCreate
+
+| Name | Type | Description | Required |
+| ---- | ---- | ----------- | -------- |
+| url | string (uri) | | No |
+| id | string | | No |
+| stages | [ [StageModelSerializerCreateExcl](#stagemodelserializercreateexcl) ] | | Yes |
+| created_at | dateTime | | No |
+| updated_at | dateTime | | No |
+| name | string | | Yes |
+| owner | string | | No |
+
+#### RunModel
+
+| Name | Type | Description | Required |
+| ---- | ---- | ----------- | -------- |
+| url | string (uri) | | No |
+| id | string | | No |
+| plan_executions | [ string (uri) ] | | No |
+| created_at | dateTime | | No |
+| updated_at | dateTime | | No |
+| start_time | dateTime | | No |
+| pause_time | dateTime | | No |
+| finish_time | dateTime | | No |
+| state | string | | No |
+| aps_job_id | string | | No |
+| plan_model | string (uri) | | Yes |
+
+#### RunModelSerializerCreate
+
+| Name | Type | Description | Required |
+| ---- | ---- | ----------- | -------- |
+| plan_model | string (uri) | | Yes |
+| slaves | [ integer ] | | Yes |
+
+#### SlaveModel
+
+| Name | Type | Description | Required |
+| ---- | ---- | ----------- | -------- |
+| url | string (uri) | | No |
+| id | string | | No |
+| name | string | | Yes |
+| address | string | | Yes |
+| port | string | | Yes |
+| state | string | | Yes |
+
+#### StageExecutionModel
+
+| Name | Type | Description | Required |
+| ---- | ---- | ----------- | -------- |
+| url | string (uri) | | No |
+| id | string | | No |
+| created_at | dateTime | | No |
+| updated_at | dateTime | | No |
+| start_time | dateTime | | No |
+| pause_time | dateTime | | No |
+| finish_time | dateTime | | No |
+| state | string | | No |
+| aps_job_id | string | | No |
+| flow_uuid | string | | No |
+| logbook_uuid | string | | No |
+| plan_execution | string (uri) | | Yes |
+| stage_model | string (uri) | | Yes |
+
+#### StageModel
+
+| Name | Type | Description | Required |
+| ---- | ---- | ----------- | -------- |
+| url | string (uri) | | No |
+| id | string | | No |
+| steps | [ string (uri) ] | | No |
+| stage_executions | [ string (uri) ] | | No |
+| created_at | dateTime | | No |
+| updated_at | dateTime | | No |
+| name | string | | Yes |
+| target | string | | No |
+| executor | string | | No |
+| trigger_type | string | | Yes |
+| trigger_args | object | | Yes |
+| plan_model | string (uri) | | Yes |
+
+#### StageModelSerializerCreate
+
+| Name | Type | Description | Required |
+| ---- | ---- | ----------- | -------- |
+| url | string (uri) | | No |
+| id | string | | No |
+| steps | [ [StepModelSerializerCreateExcl](#stepmodelserializercreateexcl) ] | | Yes |
+| created_at | dateTime | | No |
+| updated_at | dateTime | | No |
+| name | string | | Yes |
+| target | string | | No |
+| executor | string | | No |
+| trigger_type | string | | Yes |
+| trigger_args | object | | Yes |
+| plan_model | string (uri) | | Yes |
+
+#### StepExecutionModel
+
+| Name | Type | Description | Required |
+| ---- | ---- | ----------- | -------- |
+| url | string (uri) | | No |
+| id | string | | No |
+| created_at | dateTime | | No |
+| updated_at | dateTime | | No |
+| start_time | dateTime | | No |
+| pause_time | dateTime | | No |
+| finish_time | dateTime | | No |
+| state | string | | No |
+| result | string | | No |
+| std_out | string | | No |
+| std_err | string | | No |
+| mod_out | string | | No |
+| mod_err | string | | No |
+| evidence_file | string | | No |
+| stage_execution | string (uri) | | Yes |
+| step_model | string (uri) | | Yes |
+
+#### StepModel
+
+| Name | Type | Description | Required |
+| ---- | ---- | ----------- | -------- |
+| url | string (uri) | | No |
+| id | string | | No |
+| step_executions | [ string (uri) ] | | No |
+| created_at | dateTime | | No |
+| updated_at | dateTime | | No |
+| name | string | | Yes |
+| attack_module | string | | Yes |
+| attack_module_args | object | | Yes |
+| is_init | boolean | | No |
+| executor | string | | No |
+| create_named_session | string | | No |
+| use_named_session | string | | No |
+| use_any_session_to_target | string | | No |
+| stage_model | string (uri) | | Yes |
+
+#### StepModelSerializerCreate
+
+| Name | Type | Description | Required |
+| ---- | ---- | ----------- | -------- |
+| url | string (uri) | | No |
+| id | string | | No |
+| created_at | dateTime | | No |
+| updated_at | dateTime | | No |
+| name | string | | Yes |
+| attack_module | string | | Yes |
+| attack_module_args | object | | Yes |
+| is_init | boolean | | No |
+| executor | string | | No |
+| create_named_session | string | | No |
+| use_named_session | string | | No |
+| use_any_session_to_target | string | | No |
+| stage_model | string (uri) | | Yes |
diff --git a/docs/2020.4.1/scenario.md b/docs/2020.4.1/scenario.md
new file mode 100644
index 0000000000000000000000000000000000000000..1077bc0f290935deadea994759643b5fce6b0e1f
--- /dev/null
+++ b/docs/2020.4.1/scenario.md
@@ -0,0 +1,12 @@
+# Attack scenario
+
+Let's start with the description of the attack scenario. I use attack scenario and Plan interchangeably - Plan is just the name of element in formal description of attack scenario.
+
+An attack scenario is a sequence of steps with some common objective. This objective may be data exfiltration, access to target systems, denial of service or any other harmful action. For the purpose of some exercises every attack should be divisible into different stages. Imagine you have to attack an infrastructure with multiple machines - each machine can be a separate stage. Or you want to attack according to some killchain, eg. first stage would be scanning of the infrastructure, second is brute force attack on credentials to found systems etc.
+
+The last and most important element of Plan description is attack step. This is the execution of attack script or tool against the target. Step can be running a metasploit exploit, or running nmap scan. Steps are dependent on each other, and so they create en execution tree, where each of them have set the list of successors based on some condition. The condition may be a success or a string value returned by it's predecessor.
+
+Putting this all together you get the whole attack scenario (called **Plan**), which is divided into different stages (called **Stage**). Every stage is set to run on specific time, as this is often required by exercise. And finally each stage consists of attack steps (called **Step**), which are organized in a non binary tree described above.
+
+You can find swagger documentation when running Cryton REST API. Just browse to ```/doc``` endpoint. Following sections only provide descriptions of functionalities you can utilize for Attack scenario execution.
+
diff --git a/docs/2020.4.1/session-mngmt.md b/docs/2020.4.1/session-mngmt.md
new file mode 100644
index 0000000000000000000000000000000000000000..10f2dcca400fabfacbe9d4eeec7b512eb6558261
--- /dev/null
+++ b/docs/2020.4.1/session-mngmt.md
@@ -0,0 +1,19 @@
+### 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
new file mode 100644
index 0000000000000000000000000000000000000000..e4a40e6a089b0fc6587593d654107b2cd8210077
--- /dev/null
+++ b/docs/2020.4.1/stage-execution.md
@@ -0,0 +1,10 @@
+# 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
new file mode 100644
index 0000000000000000000000000000000000000000..657313c96265712425f47ab5081aa791476536bb
--- /dev/null
+++ b/docs/2020.4.1/stage.md
@@ -0,0 +1,37 @@
+
+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
new file mode 100644
index 0000000000000000000000000000000000000000..b9e391b061b91b12a5e91d5dbde6c73478a4f4c0
--- /dev/null
+++ b/docs/2020.4.1/step-execution.md
@@ -0,0 +1,19 @@
+# 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/2020.4.1/step.md b/docs/2020.4.1/step.md
new file mode 100644
index 0000000000000000000000000000000000000000..fc5abe096debbe24f918c77b070e190c526fb9b0
--- /dev/null
+++ b/docs/2020.4.1/step.md
@@ -0,0 +1,144 @@
+
+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
+
+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
+
+ Which value you want to compare, according to output of the parent Step.
+
+| Type | Meaning |
+| --------- | ----------------------------------------- |
+| `state` | Final state of the Step. |
+| `results` | Result of the Step. |
+| `std_out` | Standard output of the Step. |
+| `std_err` | Standard error output of the Step. |
+| `mod_out` | Standardized module output (JSON). |
+| `mod_err` | Module error output. |
+| `any` | Any step's result will be taken as valid. |
+
+##### value
+
+ The desired value of the selected type. Can be defined as string (one value) or list of strings (multiple values).
+
+| Value | Meaning/Options |
+| --------- | ------------------------------------------------------------ |
+| `state` | FINISHED |
+| `results` | OK, FAIL, EXCEPTION |
+| `std_out` | String that can be found in step's std_out or regex in form `r'<regex>'` |
+| `std_err` | Same principle as std_out |
+| `mod_out` | Same principle as std_out |
+| `mod_err` | Same principle as std_out |
+| `any` | - |
+
+
+
+##### step
+
+ Name of the Step's successor(s).
+ Can be string (one successor) or list of strings (multiple successors).
+
+For example:
+```
+next:
+- type: result
+ value: OK
+ step: step-to-execute
+```
+
+### Output sharing
+
+There are two techniques for sharing outputs of modules between steps:
+
+* **output_prefix**
+* **output_mapping**
+
+#### 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.
+
+Alternatively, this prefix can be set to custom string. This way, multiple equivalent steps can return the same prefixed variable value to be used by a dependent step.
+For example:
+```yaml
+- name: brutefoce
+ is_init: true
+ attack_module: mod_bruteforce
+ # Should return username and password in a dictionary
+ attack_module_args:
+ usename: admin
+ output_prefix: custom_prefix
+ next:
+ - type: result
+ value: OK
+ step: mod_ssh
+- name: mod_ssh
+ attack_module: mod_ssh
+ attack_module_args:
+ username: admin
+ 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).
+
+```yaml
+- name: stepA
+ ...
+ next:
+ - type: ...
+ value: ...
+ step: stepB
+- name: stepB
+ ...
+ attack_module_args:
+ 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.
+```yaml
+- name: step_a
+ # Returns 'token'
+ attack_module: mod_a
+ output_prefix: steal
+ output_mapping:
+ - name_from: token
+ name_to: stolen_token
+- name: step_b
+ # Returns 'auth_token'
+ attack_module: mod_b
+ output_prefix: steal
+ output_mapping:
+ - name_from: auth_token
+ name_to: stolen_token
+- name: step_c
+ attack_module: mod_c
+ attack_module_args:
+ token: $steal.stolen_token
+```
+### Example
+
+```yaml
+- 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: get-passwd
+ is_init: true
+ attack_module: misc/mod_cmd
+ attack_module_args:
+ cmd: cat /etc/passwd
+ use_any_session_to_target: 192.168.56.103
+```
diff --git a/mkdocs.yml b/mkdocs.yml
index 5e0c7ebf1994321faefa5493aaa2852da8e526a2..96085101c3b7363305422ef117dff7619ae07e78 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -14,279 +14,41 @@ extra:
nav:
- Home: index.md
-# - Documentation:
-# - 2023.1.x (future):
-# - Architecture: 2023.1/architecture.md
-# - Starting point:
-# - Core: 2023.1/starting-point/core.md
-# - Worker: 2023.1/starting-point/worker.md
-# - Modules: 2023.1/starting-point/modules.md
-# - CLI: 2023.1/starting-point/cli.md
-# - Frontend: 2023.1/starting-point/frontend.md
-# - Deployment with Ansible: 2023.1/starting-point/ansible.md
-# - Testing environment: 2023.1/starting-point/testing-environment.md
-# - Getting started:
-# - Local deployment: 2023.1/getting-started/installation-example.md
-# - Simple Workflow: 2023.1/getting-started/workflow-example.md
-# - Designing phase:
-# - What is an attack scenario: 2023.1/designing-phase/what-is-attack-scenario.md
-# - Template:
-# - What is a template: 2023.1/designing-phase/template.md
-# - Plan: 2023.1/designing-phase/plan.md
-# - Stage: 2023.1/designing-phase/stage.md
-# - Step: 2023.1/designing-phase/step.md
-# - Plan instance: 2023.1/designing-phase/plan-instance.md
-# - Session management: 2023.1/designing-phase/session-management.md
-# - Execution phase:
-# - What is Run: 2023.1/execution-phase/run.md
-# - Execution statistics: 2023.1/execution-phase/execution.md
-# - Reporting: 2023.1/execution-phase/reporting.md
-# - Interfaces:
-# - CLI: 2023.1/interfaces/cli.md
-# - Frontend: 2023.1/interfaces/frontend.md
-# - Core (REST API): 2023.1/interfaces/core-rest-api.md
-# - Worker (Rabbit API): 2023.1/interfaces/worker-rabbit-api.md
-# - Attack modules:
-# - How to create an attack module: 2023.1/modules/howto-create-attack-modules.md
-# - Modules:
-# - mod_cmd: 2023.1/modules/mod_cmd.md
-# - mod_medusa: 2023.1/modules/mod_medusa.md
-# - mod_msf: 2023.1/modules/mod_msf.md
-# - mod_nmap: 2023.1/modules/mod_nmap.md
-# - mod_script: 2023.1/modules/mod_script.md
-# - mod_wpscan: 2023.1/modules/mod_wpscan.md
-# - Integrated tools:
-# - Metasploit: 2023.1/integrated-tools/metasploit.md
-# - Empire: 2023.1/integrated-tools/empire.md
-# - Dynamic execution: 2023.1/dynamic-execution.md
-# - Logging: 2023.1/logging.md
-#
-# - 2022.2.x (latest):
-# - Architecture: 2022.2/architecture.md
-# - Starting point:
-# - Core: 2022.2/starting-point/core.md
-# - Worker: 2022.2/starting-point/worker.md
-# - Modules: 2022.2/starting-point/modules.md
-# - CLI: 2022.2/starting-point/cli.md
-# - Frontend: 2022.2/starting-point/frontend.md
-# - Deployment with Ansible: 2022.2/starting-point/ansible.md
-# - Testing environment: 2022.2/starting-point/testing-environment.md
-# - Getting started:
-# - Local deployment: 2022.2/getting-started/installation-example.md
-# - Simple Workflow: 2022.2/getting-started/workflow-example.md
-# - Designing phase:
-# - What is an attack scenario: 2022.2/designing-phase/what-is-attack-scenario.md
-# - Template:
-# - What is a template: 2022.2/designing-phase/template.md
-# - Plan: 2022.2/designing-phase/plan.md
-# - Stage: 2022.2/designing-phase/stage.md
-# - Step: 2022.2/designing-phase/step.md
-# - Plan instance: 2022.2/designing-phase/plan-instance.md
-# - Session management: 2022.2/designing-phase/session-management.md
-# - Execution phase:
-# - What is Run: 2022.2/execution-phase/run.md
-# - Execution statistics: 2022.2/execution-phase/execution.md
-# - Reporting: 2022.2/execution-phase/reporting.md
-# - Interfaces:
-# - CLI: 2022.2/interfaces/cli.md
-# - Frontend: 2022.2/interfaces/frontend.md
-# - Core (REST API): 2022.2/interfaces/core-rest-api.md
-# - Worker (Rabbit API): 2022.2/interfaces/worker-rabbit-api.md
-# - Attack modules:
-# - How to create an attack module: 2022.2/modules/howto-create-attack-modules.md
-# - Modules:
-# - mod_cmd: 2022.2/modules/mod_cmd.md
-# - mod_medusa: 2022.2/modules/mod_medusa.md
-# - mod_msf: 2022.2/modules/mod_msf.md
-# - mod_nmap: 2022.2/modules/mod_nmap.md
-# - mod_script: 2022.2/modules/mod_script.md
-# - mod_wpscan: 2022.2/modules/mod_wpscan.md
-# - Integrated tools:
-# - Metasploit: 2022.2/integrated-tools/metasploit.md
-# - Empire: 2022.2/integrated-tools/empire.md
-# - Dynamic execution: 2022.2/dynamic-execution.md
-# - Logging: 2022.2/logging.md
-#
-# - 2022.1.x:
-# - Architecture: 2022.1/architecture.md
-# - Deployment guide:
-# - Core: 2022.1/deployment/deploy-core.md
-# - Worker: 2022.1/deployment/deploy-worker.md
-# - Modules: 2022.1/deployment/deploy-modules.md
-# - CLI: 2022.1/deployment/deploy-cli.md
-# - Frontend: 2022.1/deployment/deploy-frontend.md
-# - Getting started:
-# - Basic example: 2022.1/getting-started/example-basic.md
-# - Advanced example: 2022.1/getting-started/example-advanced.md
-# - Designing phase:
-# - What is an attack scenario: 2022.1/designing-phase/what-is-attack-scenario.md
-# - Template:
-# - What is a template: 2022.1/designing-phase/template.md
-# - Plan: 2022.1/designing-phase/plan.md
-# - Stage: 2022.1/designing-phase/stage.md
-# - Step: 2022.1/designing-phase/step.md
-# - Plan instance: 2022.1/designing-phase/plan-instance.md
-# - Session management: 2022.1/designing-phase/session-management.md
-# - Execution phase:
-# - Run:
-# - What is a Run: 2022.1/execution-phase/run.md
-# - Run Control: 2022.1/execution-phase/run-control.md
-# - Reporting: 2022.1/execution-phase/reporting.md
-# - Execution statistics: 2022.1/execution-phase/execution.md
-# - Interfaces:
-# - CLI: 2022.1/interfaces/cli.md
-# - Frontend: 2022.1/interfaces/frontend.md
-# - Core (REST API): 2022.1/interfaces/core-rest-api.md
-# - Worker (Rabbit API): 2022.1/interfaces/worker-rabbit-api.md
-# - Attack modules:
-# - What is an attack module: 2022.1/modules/attack-modules.md
-# - How to create an attack module: 2022.1/modules/howto-create-attack-modules.md
-# - Modules:
-# - mod_cmd: 2022.1/modules/mod_cmd.md
-# - mod_medusa: 2022.1/modules/mod_medusa.md
-# - mod_msf: 2022.1/modules/mod_msf.md
-# - mod_nmap: 2022.1/modules/mod_nmap.md
-# - mod_script: 2022.1/modules/mod_script.md
-# - mod_wpscan: 2022.1/modules/mod_wpscan.md
-# - Integrated tools:
-# - Metasploit: 2022.1/integrated-tools/metasploit.md
-# - Empire: 2022.1/integrated-tools/empire.md
-# - Logging: 2022.1/logging.md
-#
-# - 2021.4.1:
-# - Architecture: 2021.4.1/architecture.md
-# - Installation guide:
-# - Core: 2021.4.1/install-core.md
-# - Worker (modules): 2021.4.1/install-worker.md
-# - CLI: 2021.4.1/install-cli.md
-# - Frontend: 2021.4.1/install-frontend.md
-# - Getting started:
-# - Basic example: 2021.4.1/example-basic.md
-# - Advanced example: 2021.4.1/example-advanced.md
-# - Designing phase:
-# - What is an attack scenario: 2021.4.1/scenario.md
-# - Template:
-# - What is a Template: 2021.4.1/template.md
-# - Plan: 2021.4.1/plan.md
-# - Stage: 2021.4.1/stage.md
-# - Step: 2021.4.1/step.md
-# - Plan instance: 2021.4.1/plan-instance.md
-# - Session management: 2021.4.1/session-mngmt.md
-# - Execution phase:
-# - Run:
-# - What is a Run: 2021.4.1/run.md
-# - Configuration: 2021.4.1/run-configuration.md
-# - Control: 2021.4.1/run-control.md
-# - Reporting: 2021.4.1/reporting.md
-# - Execution statistics: 2021.4.1/execution.md
-# - Interfaces:
-# - CLI: 2021.4.1/cli.md
-# - Frontend: 2021.4.1/frontend.md
-# - REST API: 2021.4.1/rest.md
-# - Worker (RabbitMQ): 2021.4.1/worker-interface.md
-# - Attack modules:
-# - What is an attack module: 2021.4.1/attack-modules.md
-# - How to create an attack module: 2021.4.1/howto-create-attack-modules.md
-# - Modules:
-# - mod_cmd: 2021.4.1/modules/mod_cmd.md
-# - mod_medusa: 2021.4.1/modules/mod_medusa.md
-# - mod_msf: 2021.4.1/modules/mod_msf.md
-# - mod_nmap: 2021.4.1/modules/mod_nmap.md
-# - mod_script: 2021.4.1/modules/mod_script.md
-# - mod_wpscan: 2021.4.1/modules/mod_wpscan.md
-# - Integrated tools:
-# - Metasploit: 2021.4.1/metasploit.md
-# - Empire: 2021.4.1/empire.md
-# - Logging: 2021.4.1/logging.md
-#
-# - 2021.2.1:
-# - 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:
-# - 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
-#
-# - 2020.4.1:
-# - 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
-# - 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
-
-# - 2019.4.1:
- - Architecture: 2019.4.1/architecture.md
- - Installation: 2019.4.1/installation.md
- - Attack scenario: 2019.4.1/scenario.md
- - Lifecycle: 2019.4.1/lifecycle.md
- - Attack modules: 2019.4.1/attack-modules.md
- - Example: 2019.4.1/example.md
- - Interfaces: 2019.4.1/interfaces.md
- - Logging: 2019.4.1/logging.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
+ - 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
- How to contribute: contribution-guide.md
- Acknowledgements: acknowledgements.md
- License: license.md