Purple Dome is a simulated and automated environment to experiment with several operating system attacking each other.
Purple Dome is a simulated and automated environment to experiment with hacking - and defense.
This tool generates an attacker VM and target VMs. Automated attacks are then run against the targets and they will log system events. Those logs will then be stored away for analysis.
PurpleDome is relevant for you:
Attacks are started from the attacker VM which is normally a Kali linux machine (with all the Kali tools) running a Caldera server for additional tooling.
* If you develop sensors for bolt on security
* If you want to test detection logic for your bolt on security
* If you want to stress test mitigation around your vulnerable apps
* Experiment with hardening your OS or software
* Want to forensically analyse a system after an attack
* Do some blue team exercises
* Want to train ML on data from real attacks
PurpleDome simulates a small busniess network. It generates an attacker VM and target VMs. Automated attacks are then run against the targets.
Depending on which sensors you picked you will get their logs. And the logs from the attacks. Perfect to compare them side-by-side.
Attacks are written as small plugins and control pre-installed tools:
* Kali command line tools
* Caldera commands
* Metasploit
That way your experiments focus on behaviour detection. And not on whack-a-mole games with malware samples.
-------------------
@ -23,11 +41,12 @@ Features
* Metasploit attacks
* Data collection: Attack log and sensor data in parallel with timestamps for matching events
* Vulnerability plugins: Modify the targets before the attack
* Sensor plugins: Write a simple wrapper around your sensor and integrate it into the experiments
Components
==========
The command line tools are the way you will interact with Purple Dome the most. Those are described in the *CLI* chapter.
The command line tools are the way you will interact with Purple Dome. Those are described in the *CLI* chapter.
The experiments are configured in YAML files, the format is described in the *configuration* chapter. You will also want to create some target VMs. You can do this manually or use Vagrant. Vagrant makes it simple to create Linux targets. Windows targets (with some start configuration) are harder and have an own chapter.
@ -9,14 +9,25 @@ To define the VMs there are also *Vagrantfiles* and associated scripts. The exam
Machines
========
Machines (targets and attacker) are configured in *experiment.yaml* - the default config file. There are different kinds of VM controllers and different communication interfaces. You will have to pick one and configure it per machine.
Machines (targets and attacker) are configured in an experiment specific yaml file (default is: *experiment.yaml*). There are different kinds of VM controllers and different communication interfaces. You will have to pick one and configure it per machine.
If you use the VM controller "vagrant" you will also have to create a Vagrantfile and link to the folder containing it.
SSH
---
SSH is the default communication interfaces. If you use Linux and Vagrant Purple Dome can use vagrant to establish SSH communication. For Windows - which needs OpenSSH installed - the configuration needs the proper keyfile specified.
SSH is the default communication interfaces. If you use Linux and Vagrant Purple Dome can use vagrant to establish SSH communication. For Windows - which needs OpenSSH installed - the configuration needs the proper keyfile specified. And you will have to manually install SSH on the windows target.
Vulnerabilities
===============
You can install vulnerabilities and weaknesses in the targets to allow your attacks to succeed (and generating more data that way). Vulnerabilities are implemented as plugins and listed by name in each machine.
Sensors
=======
Each machine can have a list of sensors to run on it. In addition there is the global *sensor_conf* setting to configure the sensors.
Sensors are implemented as plugins.
Attacks
=======
@ -28,19 +39,42 @@ Caldera attacks (called abilities) are identified by a unique ID. Some abilities
All Caldera abilities are available. As some will need parameters and Caldera does not offer the option to configure those in the YAML, some caldera attacks might not work without implementing a plugin.
kali_attacks
------------
In the YAML file you will find two sub-categories under caldera_attacks: linux and windows. There you just list the ids of the caldera attacks to run on those systems.
plugin_based_attacks
--------------------
Kali attacks are kali commandline tools run. Those are executed by specific Purple Dome plugins. Only Kali tools dupported by a plugin are available. You can reference them by the plugin name.
Kali attacks are kali commandline tools run. Metasploit attacks are metasploit steps to run against the target. Both are executed by specific Purple Dome plugins. You can reference them by the plugin name.
kali_conf
---------
In the YAML file you will find two sub-categories under plugin_based_attacks: linux and windows. There you just list the plugin names to run on those systems.
All kali attacks can have a special configuration. The configuration is attack tool specific.
attack_conf
-----------
All plugin based attacks can use configuration. This is in plugin-name sub categories in here.
Example config file
===================
The example defines four machines:
* A kali attacker
And three targets
* target1 (an old Linux, Ubuntu managed)
* target2 (Vagrant managed Windows. Pre installed)
* target3 (Ubuntu 20.10, Created by Vagrant)
It also defines the pre-installed sensors and the vulnerabilities active on each machine.
Next it sets the attack configuration (nap time between attacks and similar) and specifies which attacks to run against which targets.
* plugin_based_attacks
* caldera_attacks
For the plugins it has plugin specific configuration in *sensor_conf* and *attack_conf*
Attack features of PurpleDome can be extended using a plugin system. Those attack plugins can start Caldera ttacks, run Kali command line tools ir use Metasploit.
Attack features of PurpleDome can be extended using a plugin system. Those attack plugins can start Caldera attacks, run Kali command line tools or use Metasploit.
An example plugin is in the file *hydra_plugin.py*. It contains a plugin class that **MUST** be based on the *AttackPlugin* class.
@ -30,7 +30,7 @@ The boilerplate contains some basics:
* name: a unique name, also used in the config yaml file to reference this plugin
* description: A human readable description for this plugin.
* ttp: The TTP number of this kali attack. See https://attack.mitre.org/
* ttp: The TTP number of this kali attack. See https://attack.mitre.org/ "???" if it is unknown "multiple" if it covers several TTPs
* references. A list of urls to blog posts or similar describing the attack
* required_files: A list. If you ship files with your plugin, listing them here will cause them to be installed on plugin init.
To experiment with different senors installed on the targets there is the sensor plugin. It contains a plugin class that **MUST** be based on the *SensorPlugin* class.
To experiment with different sensors installed on the targets there is the sensor plugin. It contains a plugin class that **MUST** be based on the *SensorPlugin* class.
The main goal of PurpleDome is to study sensor technology, which data they can collect and how to create an accurate picture of what happens during an attack. So this can be one of the most important plugin classes to extend.
Usage
=====
@ -11,7 +13,7 @@ To create a new plugin, start a sub-folder in plugins. The python file in there
If the plugin is activated for a specific machine specific methods will be called to interact with the target:
* prime: Easrly installation steps, can trigger a reboot of the machine by returning True
* prime: Easly installation steps, can trigger a reboot of the machine by returning True
* install: Normal, simple installation. No reboot
* start: Start the sensor
* stop: Stop the sensor
@ -29,9 +31,8 @@ The boilerplate contains some basics:
Additionally you can set *self.debugit* to True. This will run the sensor on execution in gdb and make the call blocking. So you can debug your sensor.
The experiment being run handles the machines. As there can be several VM controllers being used this is handled by the plugin layer as well. Those machines can be target or attack machines.
The experiment being run handles the machines. Those machines can be targets or attacker machines. Different types of machine controllers are covered by those plugins.
A VM plugin handles several things:
@ -32,12 +32,27 @@ The boilerplate contains some basics:
* description. A human readable description for this plugin.
* required_files: A list. If you ship files with your plugin, listing them here will cause them to be installed on plugin init.
Some relevant methods are
Some relevant methods that must be implemented (even if they will not contain code) are:
process_config
--------------
up
--
The configuration for this machine is a sub-section in the experiment config. As the different machinery systems might require special handling, you can parse the config in this section and add your own processing or defaults
Starts the machine
create
------
Creates the machine. Vagrant for example can create machines based on config files.
halt
----
Stop the machine
destroy
-------
Destroy the machine
get_state
---------
@ -52,7 +67,6 @@ Get the ip of the machine. If the machine is registered at the system resolver (
The plugin class
================
The machine class can also be very essential if you write attack plugins. Those have access to the kali attack and one or more targets. And those are Machinery objects.
To leave attack traces on a machine it should be vulnerable. Services should run. Old application be installed, users with weak passwords added to the system. You get the idea.
For an attack leave attack traces on a machine it should be vulnerable. Services should run. Old application be installed, users with weak passwords added to the system. You get the idea.
For you as a user to be flexible there is a vulnerability plugin type that (surprise !) adds vulnerabilities to targets.
This plugin type allows you to punch some holes into the protection of a machine. Which vulnerability plugins are loaded for a specific target is defined in the configuration file. Feel free to weaken the defenses.
@ -20,19 +22,19 @@ The boilerplate contains some basics:
* name: a unique name, also used in the config yaml file to reference this plugin
* description: A human readable description for this plugin.
* ttp: The TTP number of this kali attack. See https://attack.mitre.org/ Just as a hint which TTP this vulnerability could be related to
* references: A list of urls to blog posts or similar describing the attack
* required_files: A list. If you ship files with your plugin, listing them here will cause them to be installed on plugin init.
* ttp: The TTP number linked to this vulnerability. See https://attack.mitre.org/ as a hint which TTP this vulnerability could be related to. If you do not know the TTP, use "???"
* references: A list of urls to blog posts or similar describing the vulnerability
* required_files: If you ship files with your plugin, listing them here will cause them to be installed on plugin init.
Method: install (optional)
--------------------------
*start*installs the vulnerability on the target. *install* is called before that. If you have to setup anything in the plugin space (and not on the target) do it here.
*start*starts the vulnerability on the target. *install* is called before that. If you have to setup anything in the plugin space (and not on the target) do it here.
Method: start
-------------
Adds the vulnerability to the machine. The most important method you can use here is "self.run_cmd" and execute a shell command.
Starts the vulnerability on the machine. The most important method you can use here is "self.run_cmd" and execute a shell command.
Thorsten Sick
4 years ago