Fix profiles display.

Generate one-line commands (e.g. powershell/bash/etc.) to load sliver binaries.

Heya,

While trying to build the project, I faced several missing dependencies. First example was packr:

$ make
packr clean
make: packr: Command not found
make: *** [Makefile:77: clean] Error 127

Not sure if this has to be mentioned in the build requirements of wrapped up in the go-assets.sh script.
Following things were required for a successful build:

• Golang packr utility: github.com/gobuffalo/packr/packr
• protobuf-compiler (protoc command)
• clone the project into $GOPATH/src/ instead of $GOPATH/src/github.com/bishopfox

Automatic per-platform (Windows/MacOS/Linux) persistence commands.

Tunnel C2 thru Chrome using the devtools protocol.

Long polling HTTP(S) listener.

Add webhooks based on event triggers, which we can easily add using the notification/observers patter that already exists.

https://docs.microsoft.com/en-us/microsoftteams/platform/concepts/bots/bots-create

A nice feature to have would be to only execute the payload if a certain set of properties on the target host match our expectations. The idea to restrict execution could help avoid automatic sandbox analysis or executing the sliver on out-of-scope systems.

Such properties could be things like:

• computer name
• domain name (when relevant)
• user name
• timezone
• etc.

This would be an optional feature during the payload generation process, and could be handle by a configuration file on the server side of things.

Add long-form help and examples to each command.

We should really write some unit tests ....

Port of something like Tokenvator to Go.

Feature to blacklist IP ranges such as Palo Alto networks, or return alternate data to requests originating from blacklisted IP ranges.

For example, instead of returning a DLL for a staged payload request from a blacklisted IP we send back JPGs of memes or /dev/random.

https://gamephreakers.com/2019/01/anti-debugging-tricks-4-hidden-threads/

Support for reverse SOCKS proxy/tunnel.

Automatically embed "canaries" into generated binaries to detect detection. For example, embed a random domain should never legitimately be resolved by the sliver implant.

Maybe integrate something like https://github.com/gen0cide/gscript

Fix the issues with gobfuscate to obfuscate symbols and package names

Probably using https://github.com/sirupsen/logrus --we can also write the JSON logs to Elastic Search or BigQuery for analysis and potential SEIM integration.

https://github.com/Microsoft/go-winio

Add QUIC as a supported transport protocol. Here is a popular Go implementation.

Some part of the sliver's windows specific code (in handlers_windows.go and ps_windows.go) are using the syscall.MustLoadDLL and syscall.MustFindProc to resolve some kernel32.dll symbols.

This is already covered by the standard Go syscall library for windows, available here. This library implements error checking, and returns the some handy structs such as Handle, or ProcessEntry32.

I think it would be much cleaner to use these API calls instead of resolving this ourselves, and bother with casting and all this boring stuff.

shell command similar to meterpreter.

Tab-complete only available commands, add tab complete for local and remote file system paths.

Support for process migration on Windows.

Small stubs that just load the DLL / shared library build of Sliver. I'm planning to call these eggs, since in the MtG lore Slivers hatch from eggs :)

Key validation fails when using HTTP(S) C2

When I run the following command sliver-server just exits and no shell is generated. This happens with and without the -s argument.

sliver > generate -o linux -m 127.0.0.1 -d -s /home/alxjsn/shell

[*] Generating new linux/amd64 sliver binary 

alxjsn at foxy in ~/go/src/sliver (master●)

We need a more structured approach for handling data, right now we rely on the filesystem a lot and it's not going to scale well with the code.

For corporate proxies.

Setting up and configuring the server, and examples of creating/deploying implants.

https://asciinema.org/docs/how-it-works

Or at least record scroll-back by default.

Clean kill command implementation that cleans up network connections, optionally deletes it's own binary.

Configure n domains/IPs per protocol for each C2 transport.

API is too complicated and the method names are too similar.

Using generate --dns <domain> --debug for a windows based implant, the following error was observed on the server
...omitted for brevity... INFO[6746] [sliver/server/c2/udp-dns.go:329] RSA Fingerprint: 45S78Cc6Ar9AIXPBbZ2DkgVZVVGf8KrWQa0mNWu6gkA INFO[6746] [sliver/server/c2/udp-dns.go:335] Failed to decrypt session init msg INFO[6746] [sliver/server/c2/udp-dns.go:202] Error during session init: crypto/rsa: decryption error DEBU[6746] [sliver/server/c2/udp-dns.go:238] ;; opcode: QUERY, status: NOERROR, id: 54534 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ...omitted for brevity...

Generating a sliver in debug mode using the -d or --debug flag results in the following line being stripped out:
log.SetOutput(ioutil.Discard) - link
As this is the only usage of the ioutil lib in this package, the compiler complains about an unused import when generating in debug mode.

Implementing a dummy Discard writer to get rid of the import could be a solution.

Implement a shellcode command that just dumps raw shellcode to a file.

Support for tunneled TCP ports.

It would be nice to have contextual help menus, instead a full list of generic/sliver commands.
I think we could leverage grumble.App.SetPrintHelp to achieve that. The basic idea would be:

• if there's no active sliver session, only show generic commands
• otherwise, display commands based on the selected sliver session agent's platform (win/linux/mac os)

Not sure if everything is feasible with grumble, but it's worth a try.

Integrate Sliver with the various MS Office payload generators that hippie and cha0tic have been working on.

It would be nice to be able to load arbitrary and execute .NET assemblies in the sliver agent (a la execute-assembly). There is already some public ground work on this (see here), and after giving it some thoughts, it should be achieved by:

• compiling the hosting DLL with sRDI
• inject the shellcode in the current process
• play with GetProcAddress to retrieve the exported functions
• profit?

That's the theory, and it still needs to be adapted.

Error:

$ make static-linux                                                             
echo 'package assets\n\nconst GitVersion = ""\n' > ./server/assets/version.go 
packr clean
rm -f ./protobuf/client/*.pb.go
rm -f ./protobuf/sliver/*.pb.go
rm -f sliver-client sliver-server *.exe
echo 'package assets\n\nconst GitVersion = "74be4e381206883cb330d9a56688478649e5a0c0"\n' > ./server/assets/version.go 
go install ./vendor/github.com/golang/protobuf/protoc-gen-go
protoc -I protobuf/ protobuf/sliver/sliver.proto --go_out=protobuf/
protoc -I protobuf/ protobuf/client/client.proto --go_out=protobuf/
cd ./server/
packr
Error: /home/alxjsn/go/src/sliver/server/assets/version.go:1:15: illegal character U+005C '\' (and 2 more errors)
Usage:
  packr [flags]
  packr [command]

Available Commands:
  build       Wraps the go build command with packr
  clean       removes any *-packr.go files
  help        Help about any command
  install     Wraps the go install command with packr
  version     prints packr version

Flags:
  -z, --compress       compress box contents
  -h, --help           help for packr
  -i, --input string   path to scan for packr Boxes (default "/home/alxjsn/go/src/sliver")
  -v, --verbose        print verbose logging information

Use "packr [command] --help" for more information about a command.

make: *** [Makefile:70: packr] Error 255

Versions:

$ make --version
GNU Make 4.2.1

$ /bin/echo --version
echo (GNU coreutils) 8.30

Fix: Using the -e argument for echo in Linux fixes the issues and parses the newlines properly.

Integrate a physical memory dumping tool to avoid having to open a process handle to lsass.exe when acquiring mimikatz-able memory dumps.

https://zeltser.com/memory-acquisition-with-dumpit-for-dfir-2/

Occasionally when reconnecting the Sliver binary will enter an infinite loop and consume 100% CPU. I suspect this is related to start() returning nil instead of error which results in the maxConnectionErrors limit never being reached.

the packaged github.com.zip containing the protobuf dep was not matching the protoc-gen-go lib I had on my system, and building the agent always failed with the following error:

undefined: proto.ProtoPackageIsVersion3

I had to repackage the dep with a fresher version of the protobuf lib.

Middleware encoders for HTTP C2 messages.

The sed command syntax in the current make file only works on MacOS

Sliver disconnect events don't always propagate correctly