*********************
Vulnerability plugins
*********************

To leave attack traces on a machine it should be vulnerable. Services should run. Old application be installed, users with weak passwords added. The configuration should be a mess.

This plugin type allows you to punch some holes into the protection of a machine. Which plugins are loaded for a specific target is defined in the configuration file.

Usage
=====

To create a new plugin, start a sub-folder in plugins. The python file in there must contain a class that inherits from *VulnerabilityPlugin*.

There is an example plugin *linux_sshd_config_issues.py* that you can use as template.

Boilerplate
-----------

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 realted 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.

Method: start
-------------

Put the code in here that adds vulnerabilities to the machine. The most important method you can use here is "self.run_cmd" and execute a shell command.

Method: stop
------------

Undo the changes after the attacks ran. If the machine is re-used (and not re-built or run from a snapshot) this will make it simpler for the user to run more experiments on slightly modified systems.

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.

The plugin class
================

.. autoclass:: plugins.base.vulnerability_plugin.VulnerabilityPlugin
   :members: