Tartarus (renamed from AtomicFireFly), is designed to automate the process of deploying and testing security products. This solution consists of a single node ElasticSearch cluster on a Rocky8 Linux guest (for CentOS/RHEL cross compatibility). The Windows node features Sysmon, Elastic Agent, and Atomic Red Team. Additionally, a Kali Linux instance with Caldera pre-packaged ensures comprehensive testing and monitoring.
RAM - 17 GB
CPU - 9 Cores*
Storage - 50 GB
*Most modern CPUs have "virtual cores" so if you have 4 physical cores you'll have 8 virtual.
RAM and Core count can be tweaked in the Vagrantfile.
You don't have to bring up all systems at once, if you are just testing Windows 12 GB of RAM and 6 CPU Cores (3 physical) is enough.
VM Name | Operating System | CPU Cores | Memory (MB) | Private IP | Components |
---|---|---|---|---|---|
tartarus-elastic | bento/rockylinux-8.7 | 4 | 8192 | 192.168.56.10 | ElasticSearch, Kibana, Fleet, Smallstep CA, Caddy |
tartarus-linux | bento/rockylinux-8.7 | 1 | 1024 | 192.168.56.20 | Elastic Agent |
tartarus-windows | gusztavvargadr/windows-10-21h2-enterprise | 2 | 4096 | 192.168.56.30 | Elastic Agent, Sysmon, Atomic Red Team |
tartarus-kali | kalilinux/rolling | 2 | 4096 | 192.168.56.129 | Caldera |
Reserved for | IP Address Range |
---|---|
Networking | 1-9 |
Security devices | 10-19 |
Linux hosts | 20-29 |
Windows hosts | 30-39 |
Adversaries | 128+ |
The Kali instance gets such a high IP so if an Opnsense firewall is added Kali can be out of "homenet" with a /25 network.
There is an issue of it reassigning itself an IP after ~10 min, am investigating.
This is not for production!
Please use as a guide / lab only, I do things like placing the elastic user password in a file
This should never be done in prod!
If an adversary gets you Elastic super-user password or root access to a node it is GAME OVER!
Bring up Elastic, Windows, Linux, Kali or all hosts with the following commands.
The Elastic cluster has to be started first if you want telemetry data!
Provisions the VMs ready for use.
vagrant up elastic windows
vagrant up elastic linux
vagrant up elastic linux windows
vagrant up elastic kali
vagrant up elastic kali windows
vagrant ssh elastic
vagrant ssh linux
vagrant ssh windows
On Windows open RDP client and connect to 127.0.0.1:53389
Username: vagrant
Password: vagrant
If you have xfreerdp
installed on Linux (change /size to whatever you want, cert ignore is to dismiss the untrusted cert warning on first login, the 127.0.0.1 can also be changed to a remote address if needed)
xfreerdp /u:"vagrant" /p:"vagrant" /v:127.0.0.1:53389 /size:1300x700 /cert:ignore
Should popup with a GUI at first boot (remember to enable x11 if you are remote)
vagrant ssh kali
Username: vagrant
Password: vagrant
All data is saved just shuts down the VM.
vagrant halt elastic
vagrant halt linux
vagrant halt windows
vagrant halt kali
Be careful here you will lose all data internal to each VM if you do this!
All main apps (Elasticsearch, Kibana, Agents, Sysmon, Go, Git except Caldera and Atomic Red Team) won't be redownloaded and are safe in the apps/ dir, however their configs and internal data like the Elasticsearch database, any custom Kibana dashboards, alerts, etc. will be deleted and reprovisioned. You have been warned!
vagrant destroy elastic
vagrant up elastic --provision
vagrant destroy linux
vagrant up linux --provision
Reprovisioning Windows will redownload Atomic Red Team every time as it doesn't go to the /apps dir!
vagrant destroy windows
vagrant up windows --provision
Reprovisioning Kali will redownload Caldera every time as it doesn't go to the /apps dir!
vagrant destroy kali
vagrant up kali --provision
We use .home.arpa.
to conform with RFC8375
Replace (Vagrant host ip) with the IP of the host machine you will run Vagrant from
Windows Powershell
Add-Content 'C:\Windows\System32\Drivers\etc\hosts' "192.168.56.10 tartarus-elastic.home.arpa"
Linux Bash
echo "192.168.56.10 tartarus-elastic.home.arpa" >> /etc/hosts
Used for remote deployments
Replace (Vagrant host ip) with the IP of the host machine you will run Vagrant from
Windows Powershell
Add-Content 'C:\Windows\System32\Drivers\etc\hosts' "(Vagrant host ip) tartarus-elastic.home.arpa"
Linux Bash
echo "(Vagrant host ip) tartarus-elastic.home.arpa" >> /etc/hosts
It is safe to ignore the HTTPS certificate warning as we generated our own self-signed certs in this instance.
You can now add the generated CA certificate root_ca.crt
saved in ./certs/ to your browser trust store and you will never see a this site is insecure" again* for this project thanks to the Smallstep CA + Caddy ACME certificate setup.
*The certs last 24 hours and sometimes (if you leave your host in hibernation for a while) the cert expires before Caddy redoes the ACME process. A simple sudo systemctl restart caddy
on the tartarus-elastic
node and you'll be golden.
Log into Kibana (local)
From your host machine
https://tartarus-elastic.home.arpa:5443
Must be via domain name now due to Caddy reverse proxy, just add an override in /etc/hosts
or C:\Windows\System32\drivers\etc\hosts
to point tartarus-elastic.home.arpa
to 192.168.56.10
Log into Kibana (remote)
https://tartarus-elastic.home.arpa:5443
Username: elastic
You can save the password in a file called "Password.txt" in the directory you ran Vagrant from, this is the password to the Superuser account so be careful!
The file is in .gitignore
however it's not good practice to save passwords to disk!
The password is also printed to the terminal / shell you ran vagrant up
from.
Once you have logged into the Kibana instance on https://tartarus-elastic.home.arpa:5443
now it is time to view the alerts.
The Windows and Linux alerts are auto enabled for you.
Search for alerts in the universal search tab, or open the burger and scroll down to the security tab.
Now search for "alerts".
You should see the alerts page (Note you might not have any alerts yet, you'd need to start the Windows host and run the EDR-Telemetry-Generator for example)
We make use of some existing Sigma rules, located in ./rules
as well I have written my own custom rules to detect Atomic Red Team activity. All rules are under DRL.
To load the custom rules replicate the .env.example
as a .env
file and delete everything after the values (so everything to the right and including the #
so it's only key=value per line).
Have Python 3 installed.
Install the requirements with a little python3 -m pip install -r requirements.txt
this will install pySigma needed to load the rules.
Run the sigmaApiLoad.py
file with a little python3 sigmaApiLoad.py
.
The rules in Elastic will start with SIGMA -
so they are easy to find.
Using the EDR-Telemetry-Generator from EDR-Telemetry
Open PowerShell and Git clone the EDR-Telemetry project and run it, Git is pre-installed for ease of use.
git clone https://github.com/tsale/EDR-Telemetry.git
It goes without saying but this should only be run on a VM, don't run it on your host OS!
& .\EDR-Telemetry\Tools\Telemetry-Generator\telemetry-generator.ps1
Now look at the Kibana alerts dashboard.
Now start Caldera and log in.
vagrant up kali
to start the Kali instance.
Bring up Caldera with cd /opt/caldera/ && python3 server.py --insecure
Now log into Caldera http://192.168.56.129:8888/
If you have issues accessing it run ifconfig eth1
in a new shell window and note down the IP results if different than the default and connect to that instead.
Username: red
Password: admin
Now you can do the usual. I highly recommend the in platform training for a better understanding.
The main inspiration for this work is from the incredible project EDR-Telemetry
The use of Vagrant as a provisioner was inspired by Jeff Geerling's excellent book Ansible for DevOps.
Look into how ART works on Linux
Think about a config file to hold variables that all scripts can pull from, like hostname, IP_ADDR, VER, etc. Could be done with an improvised .env
file and functions to export all vars local to each script?
Think about password saving
Add a new API call to create an API user and use that for all other curl authentications and then the API key can be shipped to other projects
Add Windows 2022 Server promoted to domain controller
Add the Auditd and Sysmon updates from Florin
Add an Opnsense node
Add a Remnux/CSI Linux node
Use Ansible to provision all the nodes for true idempotence
Look into a cloud deployment mode of Elastic like I did in https://github.com/ScioShield/Elastic-Cloud-Agent for those who don't have 64GB RAM :) This will need two scrips (a .ps1 and a .sh) to do all the config and change the Vagrantfile. I'd rather provisioning happen on the host and the guest can be as isolated as needed.
YOU ARE RESPONSIBLE FOR ENSURING YOU COMPLY WITH ALL APPLICABLE LICENSES, LOCAL AND/OR INTERNATIONAL LAW(S)!
All licenses are valid at the time of commit !
- All original work in this project (except the Sigma Rules) is licensed under The Unlicense
- Vagrant is licensed under Business Source License 1.1
- VirtualBox is licensed under The GNU General Public License (GPL) Version 3
- Rocky Linux is licensed under BSD 3-Clause
- Kali Linux is licensed under EULA
- Windows is licensed under Windows 10 Enterprise Evaluation
- Elastic is licensed under the Elastic License 2.0
- EDR-Telemetry is unlicensed
- Caldera is licensed under the Apache 2.0 License
- Atomic Red Team is licensed under the MIT LIcense
- pySigma is licensed under GNU Lesser General Public License v2.1
- Sigma Rules are licensed under the DRL 1.1
- Caddy is licensed under Apache License 2.0
- Smallstep is licensed under Apache License 2.0
Supporting software (like bash, wget, jq, etc) are also licensed under their respective licenses.
Anything not directly mentioned above does of course retain it's license!