SILENTTRINITY v0.4.6 releases: An asynchronous, collaborative post-exploitation agent
SILENTTRINITY is modern, asynchronous, multiplayer & multiserver C2/post-exploitation framework powered by Python 3 and .NETs DLR.
Some of the main features that distinguish SILENTTRINITY are:
- Multi-User & Multi-Server – Supports multi-user collaboration. Additionally, the client can connect to and control multiple Teamservers.
- Client and Teamserver Built-in Python 3.7 – Latest and greatest features of the Python language are used, heavy use of Asyncio provides ludicrous speeds.
- Real-time Updates and Communication – Use of Websockets allow for real-time communication and updates between the Client and Teamserver.
- Focus on Usability with an Extremely Modern CLI – Powered by prompt-toolkit.
- Dynamic Evaluation/Compilation Using .NET Scripting Languages – The SILENTTRINITY implant Naga, is somewhat unique as it uses embedded third-party .NET scripting languages (e.g. Boolang) to dynamically compile/evaluate tasks, this removes the need to compile tasks server side, allows for real-time editing of modules, provides greater flexibility and stealth over traditional C# based payloads and makes everything much more light-weight.
- ECDHE Encrypted C2 Communication – SILENTTRINITY uses Ephemeral Elliptic Curve Diffie-Hellman Key Exchange to encrypt all C2 traffic between the Teamserver and its implant.
- Fully Modular – Listeners, Modules, Stagers and C2 Channels are fully modular allowing operators to easily build their own.
- Extensive logging – Every action is logged to a file.
- Future proof – HTTPS/HTTP listeners are built on Quart & Hypercorn which also support HTTP2 & Websockets.
How it works
.NET runtime support
The implant needs .NET 4.5 or greater due to the IronPython DLLs being compiled against .NET 4.0, also there is no ZipArchive .NET library prior to 4.5 which the implant relies upon to download the initial stage containing the IronPython DLLs and the main Python code.
Reading the source for the IronPython Compiler it seems like we can get around the first issue by directly generating IL code through IKVM (I still don’t understand why this works). However, this would require modifying the compiler to generate a completely new EXE stub (definitely feasible, just time consuming to find the proper IKVM API calls).
Currently, the implant only supports C2 over HTTP 1.1, .NET 4.5 seems to have a native WebSocket library which makes implementing a WS C2 channel more than possible.
HTTP/2 client support for .NET’s HttpClient API is in the works, just not yet released.
The implant and server design are very much “future proof” which should make implementing these C2 Channels pretty trivial when the time comes.
- – Reworked entire directory structure in order to accomodate packaging via Shiv
- – Added some more tests
- – Logs and certs now get stored to ~/.st
Copyright (C) 2019 byt3bl33d3r