This is a research command and control framework. What I mean by this, is that it is meant for research purposes. It is not meant to fully replace cobalt strike and all your other c2s for production ops.

When I decided to write this project, I did so for a learning experience. I wanted to sit and try to plan out the design, and run into all the pitfalls along the way and have to solve them for myself.

As the project has matured, I have begun to implement other tools or techniques from various other malware authors. I will try to always cite the original sources, the best that I can.

If you notice any lack of attribution, please bring it to my attention so that I can add the credit, as it should be. Sometimes I cannot always find the original source, in which cases, I have specified that as well.

Because this is a research c2, the project moves at a slower pace and runs into a lot of issues along the way. So please understand that this is why.

What I suggest for how to use this project, is to fork it, modify it, make it your own. Even better, write your own from scratch, using this code as a reference.

Read the code, learn the particular techniques, the “why” of certain design decisions, and make your own c2. That’s really the point and in my opinion, the most effective use of this framework.

Check The ‘SetupGuide.md’ For Quick Setup (TODO)

The setup guide is being rewritten for public release. For now, the Anvil server has a README that will help you get started standing up the server.

With the server built, you ‘cargo build –release’ conduit, connect to Anvil, and use the build function to build implants. More documentation is on the way.

Now I will provide a bit of a roadmap and current architecture.

Current Tech Stack: (100% Rust)

  1. Server: Anvil
    • actix.rs & tokio
    • https
    • api for imps (implants)
    • api for conduit (hacker TUI client)
    • internal functions (implant builder + shellcode generation)
    • sqlite db (rusqlite)
  2. Implant: Imp
    • platform-specific imps (windows, linux, mac)
    • payload options as executable, dll, or shellcode (shellcode – windows only)
    • simple, yet effective design
    • designed with OPSEC in mind. no post-ex module bloat
    • modular builds, moving toward giving operators control over granular options
  3. TUI Client: conduit
    • main way of interacting with the server
    • Terminal User Interface (TUI) with realtime dashboard display
    • user friendly
    • cross-platform
    • looks cool to your old hacker friends
    • scrollable fields (PgUp + PgDn on implants field. Up + Down for output field)

LEAVE A REPLY

Please enter your comment!
Please enter your name here