Closed Cyb3rWard0g closed 4 years ago
Also, in case you wonder, the second agent was launched successfully, but I still gets stuck.
Some more context: When the new agent triggers and connects with Caldera, I get the following logs :
I see the
2020-04-28 16:22:40 - ERROR (contact_http.py:34 _beacon) Malformed beacon: Request Entity Too Large
Message. Idk if that has something to do with it.
Thank you in advance!
Does the 2020-04-28 16:22:40 - ERROR (contact_http.py:34 _beacon) Malformed beacon: Request Entity Too Large
error keep occurring during execution? Or do you only see it once?
CALDERA should "timeout" on this ability and continue execution after about 60 seconds.
This happens every time I run that step.
It happens only once and it seems that the timeout doesnt work for it because it just hangs in there. I tried it several times and I get the same outcome.
Could you please post your facts file (data/sources/4fb34bde-b06d-445a-a146-8e35f79ce546.yml
), and the options you're using to run the operation?
Example:
Sure
This is my facts file: https://github.com/OTRF/mordor-labs/blob/master/environments/attack-evals/apt29/caldera/conf/4fb34bde-b06d-445a-a146-8e35f79ce546.yml
and your image looks has everything I use but the red
group only. That is because there is red-dll
hardcoded on this file: https://github.com/mitre-attack/attack-arsenal/blob/bc0ba1d88d026396939b6816de608cb279bfd489/adversary_emulation/APT29/CALDERA_DIY/evals/data/abilities/host-provision/865b6ad9-ba59-435a-bd8f-641052fc077a.yml . I assume that if I only use red and not All groups, then I would miss red-dll
Hmm, this is very odd. On a fresh pull in a clean environment I could not recreate the issue.
Are you running a non-elevated sandcat agent executable on the remote host, and then starting APT-29 Day 2 or are you using the red-dll from a previously executed day-2 operation?
With regards to fetching and executing commands neither should matter, I just want to ensure I'm re-creating exactly your environment.
Additionally, don't forget to run the setup.py script to avoid call back issues later in execution.
thats awesome! would you mind sharing what you mean with "fresh pull"? I just want to make sure I am using the right branch and everything. My environment is set to Caldera with 192.168.0.4 so no need to update all the scripts pointing to it already. Also, I am running Caldera as a docker container to simplify the set up. However, I would like to know exactly what commands you are running to set up Caldera and the plugin. Mine is :
git clone --recursive --branch 2.6.6 https://github.com/mitre/caldera.git /opt/caldera
cd /opt/caldera
pip3 install --no-cache-dir -r requirements.txt
git clone https://github.com/mitre-attack/attack-arsenal
cp -r attack-arsenal/adversary_emulation/APT29/CALDERA_DIY/evals plugins/evals
python3 server.py
I use the facts file of course that I shared earlier. That's it.
I apologize, by "fresh pull" I meant I re-cloned caldera and re-cloned the evals plugin in a fresh directory to ensure I didn't have any additional abilities hanging around that could be resulting in the success. Additionally, I created a new Windows Server to run Day 2 on.
As far as the commands to get Caldera setup I'm leveraging the virtual environment created after running the install.sh script and then executing:
python3 server.py --fresh
The --fresh
will delete any previous configuration/reports so please use with caution.
no worries. Just making sure I was not missing any step. ok let me try that today. thank you @jaredestroud !! I appreciate it :)
oh but just to make sure. You are using branch/tag 2.6.6 right?
Yes!
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: https://github.com/mitre-attack/attack-arsenal/pull/2 thats why the host-provision step works.
The last script/commands executed was:
Thank you in advance!