CALDERA plugin: WORM

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.

Requirements and quick start

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.

Functionality

This plugin introduces the following features:

• a new type of operation: worm-operation
• a new class of planners: worm-planners
• a new concept: goal
• a new report for worm-operations
• easily separating the agents which - by participating in an worm-operation - have satisfied the goal by those which have not satisfied it

It is possible to use these features both via REST API and GUI.

WHY this plugin

Using "normal" CALDERA operations with adversary profiles that perform lateral movements, some inconsistent or unwanted scenarios can occur. Examples:

• new agents created after a lateral movement operation could perform the attack phases in an unexpected order - due to the forced recovery of the phases already executed (by the "old" agents) as if they were a single phase.
• after the creation of new agents, some abilities of phases already executed could be repeated - due to new facts collected by the new agents and by the new potential links that can be generated starting from them.
• new agents created during the last phase never start the operation.
• new agents created during the last but one phase phase may not execute certain abilities - in particular those that use variables that can only be filled with host-facts (the facts with property major component = host), that the previous abilities have collected.

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

WORM-OPERATION

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:

• if a worm-operation is stopped, it cannot be restarted - like the normal operation - but is considered completely terminated.
• manual approval is not possible for worm-operations.

The two last features may change in the future.

Note 1: don't be misled by the name worm-operation!

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.

Note 2: build the 'agents family tree'

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)

WORM-PLANNERS

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.

The worm_sequential planner

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.

GOAL

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:

• on agent's properties.
  
• on host-facts (the facts with property major component = host) collected by an agent.

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:

REPORT

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:

• goal: if set one, it shows the name and description
• policy: if the worm-operation had a goal, it shows the chosen policy - stop at the first goal-agents / expand until it is possible.
• goal-agents: percentage of goal-agents and list of their paw.

Additional features for AGENTS

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:

• compare the results of a finished worm-operation with other goals - associated with the same adversary profile executed.
• split easily the goal-agents from the no-goal-agents that participated in a worm-operation into distinct groups.

Possible integration

The WORM plugin could be completely integrated with the CALDERA core system and the CHAIN plugin by:

1. by introducing the father parameter for agents (PR)
2. extending the concept of goals also to normal CALDERA operations
3. adding the agent-map section even to normal CALDERA operations
4. entering the possibility to run an adversary profile choosing between the two different logics: giving priority to the phases and then to the agents (normal CALDERA operations logic), or giving priority to the agents and then to the phases (worm-operations logic)