Specifications
EC2 instance --> t2.micro
OS --> Ubuntu 20.04LTS (Focal Fossa)
Go Version --> go1.20.1 linux/amd64
Sliver Version --> 1.5.34
Mingw Version --> 7.0.0-2
Preparation
My journey began with the launch of an Ubuntu 20.04LTS t2-micro (free tier) instance. I will recommend configuring the security group to only allow access from your own IP for better OpSec. After launching the instance, I did sudo chmod 400 <key.pem> to make it readable only to my user account and SSHed into the instance.
Go Installation
Since Go is not installed by default, I fetched the latest version from the go.dev website using the below command.
wget https://go.dev/dl/go1.20.1.linux-amd64.tar.gz
After that, the next step was to copy the archive to /usr/local and extract the contents.
sudo cp go1.20.1.linux-amd64.tar.gz /usr/local/
cd /usr/local/ && sudo tar -xzf go1.20.1.linux-amd64.tar.gz
After extracting the archive, the remaining portion was to add this directory to my path. For this, I added export PATH=$PATH:/usr/local/go/bin to my ~/.bashrc file so it can persist between reboots.
Mingw Installation
To enable shellcode/staged/DLL payloads MinGW must be installed on the server. Since the majority of my testing is to be done on Windows systems, I installed it using the below command.
sudo apt install mingw-w64
Metasploit Installation
Sliver authors also recommend installing Metasploit for some integrations, however, I skipped it for the time being.
Sliver
Installation
Now that all that dependencies are installed it was time to download the sliver binaries.
wget https://github.com/BishopFox/sliver/releases/download/v1.5.34/sliver-server_linux
wget https://github.com/BishopFox/sliver/releases/download/v1.5.34/sliver-server_linux.sig
wget https://github.com/BishopFox/sliver/releases/download/v1.5.34/sliver-client_linux
wget https://github.com/BishopFox/sliver/releases/download/v1.5.34/sliver-client_linux.sig
And made the binaries executables.
sudo chmod 755 sliver-server_linux
sudo chmod 755 sliver-client_linux
Since this is mainly a research project, I decided to rename & move these binaries to the Home directory for the sake of convenience and changed the file ownership.
sudo mv sliver-server_linux server
sudo mv sliver-client_linux client
mkdir ~/sliver
sudo chown ubuntu:ubuntu server
sudo chown ubuntu:ubuntu client
sudo mv client ~/sliver/
sudo mv server ~/sliver/
Next up the verification of these binaries was also necessary. Ideally, it should be done right after downloading binaries.
wget https://raw.githubusercontent.com/BishopFox/sliver/master/server/assets/fs/sliver.asc
gpg --import sliver.asc
gpg --verify sliver-client_linux.sig client
gpg --verify sliver-server_linux.sig server
Then I thought why not make this as a systemd service so created a file ( sliver.service ) in my home directory with the following content. This is to ensure that the user ubuntu remains the file owner instead of root. However, the ownership can be easily changed by:
sudo chown $USER:$USER <filename>
Now here's the content for systemd file.
[Unit]
Description=Sliver
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=on-failure
RestartSec=3
User=ubuntu
ExecStart=/home/ubuntu/sliver/server daemon
[Install]
WantedBy=multi-user.target
And moved this file to /etc/systemd/system using sudo chmod 600 sliver.service && sudo mv sliver.service /etc/systemd/system/. Then ran sudo systemctl start sliver and set it to start every reboot using sudo systemctl enable sliver. Now just to be sure that sliver is up and running, I pulled the status using sudo systemctl status sliver which gave the following output.
Now with sliver running, I wanted to check which port it was listening on. Since netstat was not included by default in my VPS, I installed it using sudo apt install net-tools and ran sudo netstat -tlp | grep server to discover it was listening on port 31337.
I also created two aliases alias server='/home/ubuntu/sliver/server' and alias client='/home/ubuntu/sliver/client' in a separate ~/.bash_aliases file for ease of access.
First Run
Now with everything set up, it was now time to run sliver server and check out the available options.
Since every red team engagement requires operators, it was time to create one. Luckily sliver has some good inbuilt help features so I ran new-operator --help and was greeted with the following manual.
So I created an operator named Ezio with new-operator --name Ezio -l 127.0.0.1 .
With server running in one terminal tab, I opened another one and SSHed into the server to run client. Do note that if you're using the same machine for both server and client, make sure to enable multiplayer mode by typing multiplayer in server terminal.
With the C2 setup ready, it was now time to set up the proper infrastructure for receiving communications from the target.
Elastic Load Balancer
The next step was to set up an Application Load Balancer and connect it to the instance running sliver.
In the EC2 Management Console, select Load Balancers, under the Load Balancing section and click on Create Load Balancer option.
Then in the popup, select Application Load Balancer (ALB) as that is the perfect for this use case.
After that, in the next few steps configure ALB and Target Group (instance to forward traffic to).
In the new tab, configure the Target group while selecting Instances and give it a descriptive name.
Then select the appropriate VPC and choose the HTTP version and click Next.
Now select the instance running sliver, click on Include as pending below and click Create target group.
Now go back to ALB page, and select Target Group and click on Create Load Balancer.
Now go back to EC2 Management Console, click on Security Groups option under Network and Security section, and select the security group attached to the instance running sliver. In that security group, click on edit inbound rules and add a new rule with Type as Custom TCP, Port range as 80, and the security group ID of the newly created load balancer as Source.
CloudFront
Now as a final step, CloudFront needs to be set up which is very easy. Select the ALB from the dropdown in Origin domain, set protocol to HTTPS only, in Allowed HTTP methods select the third option (GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE), choose Caching Optimized under Cache policy, and click on Create Distribution and copy Distribution domain name from next page. This Distribution domain name will now be our C2 domain which we can use since Cloudfront is being trusted in many organizations without the risk of triggering some security systems. Now there are some interesting configurations in CloudFront like adding a custom header to client requests and sending logs to s3 buckets among others which I plan to dig into later.
So with the CloudFront done, we can now go back to sliver and continue the testing by generating implants/beacons and having fun with a sophisticated C2 setup in the public cloud.
That's it for this blog, I'll be back with Part-2 soon. Feel free to drop your suggestions below.