Adlerschlag

I am building a command and control (C2) program to learn C2 software design and implementation at a fine-grained level (using MITRE ATT&CK C2 Techniques and existing C2 software as references) as a company product named “Adlerschlag” for research and training purposes.

This project is under active development, so the core goals and features will likely change over time but should be pretty much the same from the beginning.

Source Code

The source code is closed.

Core Goals

  • Small binary size.
    • Small as possible to fit in small places and have minimal data transfer to a target location.
  • Lean on resources.
    • Mainly CPU and memory.
      • I use small ARM SoCs and limited resource VMs as testing servers, for example. It would be awesome to have a rpi0w work as a server in a usable manner.
  • Handle a large number of active agents and operators.
    • Unsure what number metric it is, but having written many client/server applications, it is bonkers that some C2s require so many resources and support so few operators and agent comms.
  • Target GNU/Linux, NetBSD, OpenBSD, FreeBSD, Windows, and macOS.
    • I will have native packages and documentation for each platform. I know them all well.
  • Competitive with other well-known C2 software out there.
    • Implement most of the features in the C2 Matrix spreadsheet. Perhaps as a personal challenge, but I want to have checkmarks across the entire row for mine.

Core Features

  • Support many server services: HTTPS, DNS over UDP, DNS over HTTPS, FTP, SMB, ICMP, SMTP, IMAP, raw TCP, and raw UDP, and I’m sure many more (shooting for more than anyone else).
    • This is probably going to get scaled back with the services used less frequently being added with each release.
  • Multi-user server and agents: multiple users can use the same server and communicate with the same agents simultaneously and independently.
  • Plugin support: Unsure of the best way to implement this yet.
  • Agent…
    • relaying: relay communications to the server via other agents and to agents via other agents (return path doesn’t have to be the same).
    • time/day schedules: only operate on certain days and times, such as work hours.
    • queues: queue multiple commands/requests.
    • multiple server service communications: optionally communicate over multiple server services (such as multiple DNS queries and then SMTP) within the same session.
    • communication playbooks: predefined communication playbooks to emulate regular traffic.
  • Asymmetric and symmetric encryption: rotating keys and using existing AES and RSA industry standards.
  • Decoupled data transmission, chunking, and modification: allowing for independence at each level, one-to-many relationships, and independent plugin support.
  • Server API: frontends can use the remote server API, allowing for a decoupled experience where user interfaces can be remote and in whatever format is needed.
  • Malleable C2 Profiles: I have planned on this being a feature from the beginning, but I simply see them as configuration files. If there’s a variable state that is to be configured or otherwise changeable, it will be possible in a configuration file.