Shlyuz Implant Framework: Part 3 - Initial Release Usage

Part 1 of this series dove into the influences of Shlyuz. Part 2 of this series dove into the architecture and research of the communication and crypto model. This part hopes to provide a quickstart guide for the current iteration of the released codebase.

Recently I gave a presentation on Shlyuz and how it works, and got some excellent feedback on viable improvements. For example, the cryptographic model could be improved using something similar to the double ratchet algorithm used by Signal. This would provide both encryption of the contents of a message, as well as authentication of the peers, along with forward secrecy and automated reestablishment of secrecy. Perhaps this DoubleRatchet package might work (I haven’t reviewed).

Cooinidentially, a stealth release of the PoC codebase was performed. I wanted to release it with the last post of this series, but as you can see, that’s not quite happening at the rate I’d like… Thus, this post will be a brief usage guide for the released version of Shlyuz.

The following components were released:

• Teamserver
• Listening Post
• Mac Implant
  • Honestly this implant probably works for any OS that runs python 3, but was developed for Mac
• Tests
  • Literally just shell scripts that interact with the teamserver API to login, issue commands, get stats, and get the status of a command

Quickstart Guide

1. Clone the teamserver to your desired location
2. Install the teamserver’s requirements. It is recommended you use a venv.
3. Run setup.py in the root of the teamserver directory to generate setup configs
4. Clone the listening post to your desired location
5. Install the listening post’s requirements. It is recommended you use a venv.
6. Place the listening post’s configuration file in the root of the project directory. You can retrieve the generated configuration from the teamserver. It should be in teamserver/setup_configs/listening_post/{listening_post_id}. Place this on the listening post in listening_post/config/shlyuz.conf.
7. Start the teamserver. Depending on your environment, the most likely way to do this will be (on the teamserver) python3 shlyuz.py -c {PATH_TO_TEAMSERVER.conf}. If you do not provide a -c switch, it will default to searching for the config in teamserver/config/shlyuz.conf. You can also enable debug logging with the -d switch.
8. Start the listening post. Depending on your environmentm, the most likely way to do this will be (on the listening post) python3 shlyuz -a {teamserver_bind_address} -p {teamserver_bind_port} -c {path_to_listeningpost.conf}. If you do not provide a -c switch, it will default to searching for the config in listening_post/config/shlyuz.conf. You can also enable debug logging with the -d switch.
9. Clone the mac_implant repo. Install the requirements.
10. Place the implant’s configuration file in the root of the project directory. You can retrieve the generated configuration from the teamserver. It should be in teamserver/setup_configs/implant/{implant_id}/shlyuz.conf. This file should be encrypted, so it may appear to be junk data.
11. Edit this line in shlyuz.py to provide the configuration key that teamserver’s setup.py told you to write down.
12. Package and distribute your implant as necessary. Deploy the implant. Upon execution you should have messages being generated on the teamserver and listening post.
13. Clone the tests repo. Edit the scripts as necessary to interact with the teamserver. The teamserver’s setup.py has a default authstring it uses, so these scripts may not require any editing. Modification of setup.py to generate a random authstring, and subsequent modification of the scripts in the tests repo is left as an exercise to the reader.

Sending a command to an implant

Presently, the provided shellscripts in the tests repo are not exactly flexible. This will change in the future, but again, understand this is a hobby project.

There are two scripts provided to you in the tests repo that are relevant to tasking an implant:

• send_shell_cmd.sh
  • Executes a raw shell command on an implant. This uses subprocess.check_output()
• send_pyexec_cmd.sh
  • Executes raw python code on the implant. This uses exec()

Input validation and/or verification is not done for any of the scripts, ensure the instructions you submit are valid. Invalid instructions may result in a crash or trigger a bug. Pull requests are encouraged.

Review each script. Change the component_id field in the script to have the value of the implant you wish to task. Review your generated configuration values to retrieve this.

Running a command will return a txid.

Retrieving the status of a task

Each task has an associated txid, representing the ID of the transaction associated with the task. A “task”, generates a “transaction”, hence txid. A transaction is defined as the series of data exchanges required to send, execute, and retrieve the output of a particular task. Think of a “transaction” as the recipet and log of work associated with a particular task.

Using the get_cmd.sh script in the tests repo, you can retrieve the status of a particular transaction, and/or its output.

The syntax for get_cmd.sh is simple. It takes one argument, the txid. A JSON object will be returned containing information about the transaction, and if applicable, output from the task.

Conclusion

This is a short post, containing basic usage instructions for the intial release of the Shlyuz framework. I understand that this is not “simple” to use, and very underfeatured. This is done intentionally for a number of reasons that are not worth expanding upon at the moment. Tasks in the Shlyuz framework may appear convoluted at first, but rest assured that this is done with intention. The architecture of tasks will become more clear in the next post in this series, which will explore assassin’s ICE standard, and more advanced execution and tasking for Shlyuz implants.

Future versions of Shlyuz contain a number of enhancements that better extend the functionality and ease-of-use. Understand that presently the codebase serves as nothing more than a proof-of-concept. I would not recommend using this in production, however, do tear through the codebase. Hopefully it can serve as either inspiration or a starting point for creating your own framework.