mitre/emu

This CALDERA Plugin converts Adversary Emulation Plans from the Center for Threat Informed Defense

MITRE Caldera Plugin: Emu

A plugin supplying Caldera with TTPs from the Center for Threat Informed Defense (CTID) Adversary Emulation Plans.

Installation

Using the Emu plugin with Caldera will enable users to access the adversary profiles contained in the CTID Adversary Emulation Library.

To run Caldera along with the Emu plugin:

1. Download Caldera as detailed in the Installation Guide
2. Enable the Emu plugin by adding - emu to the list of enabled plugins in conf/local.yml or conf/default.yml (if running Caldera in insecure mode)
3. Start Caldera to automatically download the Adversary Emulation Library to the data folder of the Emu plugin.
4. Stop Caldera.
5. Some adversaries may require additional payloads and executables to be downloaded. Run the download_payloads.sh script to download these binaries to the payloads directory.
6. Start Caldera again. You will see the Emu plugin shown on the left sidebar of the Caldera server, and you will be able to access the Adversary Emulation Library adversary profiles from the Adversary tab of the Caldera server.

Additional setup

Each emulation plan will have an adversary and a set of facts. Please ensure to select the related facts to the adversary when starting an operation.

Because some payloads within the Adversary Emulation Library are encrypted, a Python script is used to automate the decryption which requires installation of some dependencies. Depending on the host OS, pyminizip can be installed using the following:

• Ubuntu: apt-get install zlib1g
• MacOS: brew install zlib
• All OS's: pip3 install -r requirements.txt

See URL for more information regarding pyminizip: https://github.com/smihica/pyminizip

Acknowledgements

• Adversary Emulation Library

emu's Issues

Search yaml files recursively

The path of the yaml file in the Adversary Emulation Library will be changed.
Why don't you try to find the yaml file recursively?

diff --git a/app/emu_svc.py b/app/emu_svc.py
index d52d677..f2f014a 100644
--- a/app/emu_svc.py
+++ b/app/emu_svc.py
@@ -36,12 +36,12 @@ class EmuService(BaseService):
         """
 
         if not path_yaml:
-            path_yaml = os.path.join(self.repo_dir, '**', '**', '*.yaml')
+            path_yaml = os.path.join(self.repo_dir, '*', '**', '*.yaml')
 
         at_total = 0
         at_ingested = 0
         errors = 0
-        for filename in glob.iglob(path_yaml):
+        for filename in glob.iglob(path_yaml, recursive=True):
             emulation_plan = self.strip_yml(filename)[0]
 
             abilities = []

APT29 Plugin execution errors

The Day 1 part completes but then the Day 2 part never starts and it just stays hug up at that point. Basically after the restart in Day 1 new bots are not created again which leads to the apt29 plugin getting stuck at Artifact cleanup phase after the scheduled task phase. Also is there any documentation on what each of the facts means so that I can verify if I have the correct things where they should be.
Also when using StealToken powershell script in the Access Token Manipulation stage I get these errors:

I think most of the errors that I am getting can be just due to misunderstanding of where which facts should go. Can you please help me understand this part?

Fin 6/7 Facts are not Replaced in the Commands

Describe the bug
When running the Operation for Adversary for FIN 6/7, the commands that are being executed are wrong. In these commands the facts file is supposed to be used to replace the traits with corresponding values but that's not happening.

To Reproduce
Steps to reproduce the behavior:

1. Enabled Emu plugin.
2. Created the operation with FIN 6/7 Adversary and then added FIN6 facts file

Expected behavior
The traits are supposed to be replaced by the corresponding values in the commands.

Screenshots
The facts for FIN6:

The command that's being executed:

The facts for FIN7

The command that's being executed:

The facts items in the sources menu will increase each time you start MITRE CALDERA

The emu plugin recreates the sources facts yaml files with a new UUID every time MITRE CALDERA is started, so it is added as a new sources facts.
Something needs to be done.

emu plugin loads unexpected/wrong payloads for apt29

Describe the bug
I think this is the correct place to open this issue since it is related to the emu plugin's emu_svc.py.

When starting a CALDERA server with enabled emu plugin and the information about APT29 from the adversary emulation library (see here), the wrong payloads are copied to plugins/emu/payloads.

I would expect the emu_svc.py to copy the payloads in plugins/emu/data/adversary-emulation-plans/apt29/resources/ (here) but instead the payloads from the archived directory plugins/emu/data/adversary-emulation-plans/apt29/Archive/CALDERA_DIY/evals/payloads (here) are copied (see output with debug-prints added below). For other emulation plans the correct directory was searched (probably because there is no "Archive" directory?)(tested with carbanak emulation plan).

I know this does not belong here but rather in the adversary-emulation-library but I still want to mention it here. Maybe I will open another issue over there as well about this.

The APT29 adversary emulation library information contains 3 payload directories in total. For example the stepFourteen_bypassUAC.ps1 payload is found 3 times in:

1. adversary-emulation-plans/apt29/resources/scenario_2/stepFourteen_bypassUAC.ps1
2. adversary-emulation-plans/apt29/Archive/Emulation_Plan/Day 2/payloads/stepFourteen_bypassUAC.ps1
3. adversary-emulation-plans/apt29/Archive/CALDERA_DIY/evals/payloads/stepFourteen_bypassUAC.ps1

The payload that will be used by the emu plugin is number 3 in the above list.
It is also worth to mention that the payloads' contents are not the same. Also this is really confusing when you want to edit the payloads (which is necessary for the attacks) because it is not clear which are really used by CALDERA.

To Reproduce
Steps to reproduce the behavior:

1. Enable emu plugin
2. Start server

Expected behavior
I would expect the emu_svc to copy the payloads from the "not-archived" directory (plugins/emu/data/adversary-emulation-plans/apt29/resources/).

Screenshots

2023-03-08 05:36:04 - DEBUG (emu_svc.py:265 _store_required_payloads) Searching for and storing required payloads.
payload timestomp.ps1
path plugins/emu/data/adversary-emulation-plans/apt29/Archive/CALDERA_DIY/evals/payloads/timestomp.ps1
target_path plugins/emu/payloads/timestomp.ps1
payload stepSeventeen_zip.ps1
path plugins/emu/data/adversary-emulation-plans/apt29/Archive/CALDERA_DIY/evals/payloads/stepSeventeen_zip.ps1
target_path plugins/emu/payloads/stepSeventeen_zip.ps1
payload plink.exe
path plugins/emu/data/adversary-emulation-plans/carbanak/Resources/step5/plink.exe
target_path plugins/emu/payloads/plink.exe
payload Invoke-Mimikatz.ps1
path plugins/emu/data/adversary-emulation-plans/apt29/Archive/CALDERA_DIY/evals/payloads/Invoke-Mimikatz.ps1
target_path plugins/emu/payloads/Invoke-Mimikatz.ps1
payload stepSixteen_SID.ps1
path plugins/emu/data/adversary-emulation-plans/apt29/Archive/CALDERA_DIY/evals/payloads/stepSixteen_SID.ps1
target_path plugins/emu/payloads/stepSixteen_SID.ps1
payload stepFourteen_bypassUAC.ps1
path plugins/emu/data/adversary-emulation-plans/apt29/Archive/CALDERA_DIY/evals/payloads/stepFourteen_bypassUAC.ps1
target_path plugins/emu/payloads/stepFourteen_bypassUAC.ps1

Desktop (please complete the following information):

• OS: Kali
• Browser: -
• Version: 4.1.0

Additional context
...

The cleanup command seems to be retrieved incorrectly

emu/app/emu_svc.py

Line 147 in 0ae1f7c

'cleanup': info['command'].strip()

diff --git a/app/emu_svc.py b/app/emu_svc.py
index 460dcf6..bb670a8 100644
--- a/app/emu_svc.py
+++ b/app/emu_svc.py
@@ -144,7 +144,7 @@ class EmuService(BaseService):
                                     {
                                         'command': info['command'].strip(),
                                         'payloads': info.get('payloads', []),
-                                        'cleanup': info['command'].strip()
+                                        'cleanup': info.get('cleanup', '').strip()
                                     }
                             }
                         })

imported adversary's abilities not created with all executors

It appears that the executors defined in the emulation library aren't all being imported, and the second listed (pwsh) is getting done instead of both psh and pwsh. For example coming from apt29 yaml adversary:

• id: 24ed020e-4730-4000-b6b4-6b5d3e95314f
    name: Remote System Discovery
    description: The net utility is executed via cmd to enumerate hosts within the domain.
    tactic: discovery
    technique:
      attack_id: T1018
      name: "Remote System Discovery"
    cti_source: "https://blog-assets.f-secure.com/wp-content/uploads/2020/03/18122307/F-Secure_Dukes_Whitepaper.pdf"
    procedure_group: procedure_discovery
    procedure_step: "4.A.3"
    platforms:
      windows:
        psh,pwsh:
          command: |
            cmd.exe /c net group "Domain Computers" /domain
    executors:
    - name: powershell
      command: |
        cmd.exe /c net group "Domain Computers" /domain

Looks like after importing to caldera via emu becomes just:
mvanopst@ubuntu:~/caldera$ cat plugins/emu/data/abilities/discovery/24ed020e-4730-4000-b6b4-6b5d3e95314f.yml

• description: The net utility is executed via cmd to enumerate hosts within the domain.
    id: 24ed020e-4730-4000-b6b4-6b5d3e95314f
    name: Remote System Discovery
    platforms:
      windows:
        pwsh:
          cleanup: ''
          command: cmd.exe /c net group "Domain Computers" /domain
          payloads: []
    repeatable: false
    requirements: []
    tactic: discovery
    technique:
      attack_id: T1018
      name: Remote System Discovery

It's problematic since even with the 'shells' extension installed to the win10 sandcat agents, I'm only set to run ["cmd","psh"] so I'm missing a bunch of the abilities from an adversary profile.

AdFind.zip from payloads requires a password

Describe the bug
AdFind.zip that is downloaded for the emu plugin now requires a password

To Reproduce
Steps to reproduce the behavior:

1. ./download_payloads.sh

Expected behavior
All payloads are downloaded and unzipped.

Screenshots
See here at the bottom in red, the zip is now protected with a password that is included in the zip itself (NotMalware)

Desktop:

• OS: Kali
• Browser: Firefox
• Version: Caldera 4.2.0