The combination of Go as a language, as a rich library ecosystem providing various networking capabilities, cross-platform functionality and execution, is a solid ground for developing a powerful, robust, extensible, and maintainable post-exploitation framework.
The grounds for the WireGost exploitation framework project are:
- Go is syntactically dead simple and has a C-like object-model: This will lower the number of abstraction-layers-caused headaches.
- Consequently, Go code is easily readable and maintainable. Go is strongly typed, which make Gophers winners on all fronts.
- Go compiles itself cross-platform: Code compiled on a Linux machine will run on virtually any architecture and operating system. The implications for payload efficiency are wide-ranging.
- Go standard library includes what is probably the most advanced networking stack at the moment. Again, the implications for both framework complexity and payload modularity are significant.
Wiregost's architecture rests on several aims and technologies:
- Protobuf for API definitions, PostgreSQL for storage, Go for runtime.
- Go for simplicity, modularity, robustness and maintainability.
- Protobuf as a language-agnostic, per-version specification of Wiregost capacities/objects
- Networking libraries in Go are powerful and the ecosystem rich: Advanced trafic management system.
- Database as a dual gRPC/REST service, for exposure to other tools.
- Use of different RPC/transport stacks, per-implant.
- Robust and powerful Console UI.
Assuming two classes of persons:
- Users of the tool can download ready-to-run binaries for their platform.
- Developers can install for development
Documentation in Wiregost is available in several forms:
- On the Wiki of this repository.
- README files, in all directories, explain the content and role of packages and source code.
The following is an overview of Wiregost codebase's main directories:
client/- Console client codeserver/- C2 Server codeghost/- Implants codemodules/- All modules available (implants, post, etc...)proto/- Protobuf messages (all objects/services used in all of Wiregost server/implants/console)db/- Database (as a service) code
You can find a more through description of the code base in the wiki page, or by browsing the repository: READMEs are available for pretty much all subpackages, explaining their role and contents.
Wiregost is currently developed in its version 1.0.0. It has gone through two major developments: a rewrite of Merlin, then of Sliver, each time with the aim of enhancing the console UI part, by providing either better context, commands or general interaction refreshments. Both projects (Merlin and Sliver) have laid foundations for the use of the Go language for implant development. Moreover, they have done so while remaining well self-contained, thanks in part to the nature of Go.
However, many strengths of the language and its ecosystem were not leveraged (network programming capacities combined with Go's type system, UI libraries, ORM engines, etc), and I found these projects could benefit from a larger share of the Go ecosystem, while retaining good operability and maintanability.
At the same time, the increasing set of RPC frameworks available in Go (some of them being almost transport-agnostic) ultimately called for an object/capacity model defined with Protobuf, so as to provide easy code generation for RPC frameworks, but also to promote cross-language implant/tool development. Therefore, Protobuf is one of the pillars of Wiregost, as explained in the proto/ directory.
Sliver is a post-exploitation/implant framework written in Go. It is the most advanced framework written in Go at the moment. This project has emphasized communication and authentication security, as well as easy implant compilation. Significant blocks of their code will be reused in Wiregost v1.0.0, for instance Certificate generation/validation code.
Merlin is also a post exploitation framework written in Go. It emphasizes on the use of HTTP/2 for C2 communications. It also includes a Javascript agent, post-exploitation modules (mostly in PowerShell) usable a-la-metasploit. Downsides are only one server capability, and no multi-client capacity either.
Computer security is as large a subject as computers alone. It goes the same for the number of tools related to it. I would gladly pay for another 30 lives so I can discover them all, but I don't have God's SWIFT account number, and I'm poor as hell. If, in the context of this project, some of them are worth so much that it would be criminal not to include them in this list, I will add them.
The name: I once felt upon a video where the notorious Kevin Mitnick is interviewed by an attractive journalist about the usual security and pricacy issues. Boring questions, boring answers (so boring that everyone comments on this instead of saying obsenities on the girl... very surprising), but he remembered me the name of his book: "Ghost in the Wires". Just on point. Thank you Mr. Mitnick.
Thanks as warm as the sun are due to:
- The Golang Project.
- BishopFox for their Sliver framework, with which I've learned a lot.
- The Merlin project, with which I learned a lot too !