C2 Architecture is one of the most important aspects of the APT world.
Proper C2 architecture lets you subvert IDS, antivirus, and network analysts.
It lets you exfiltrate data. It lets you move laterally across networks while raising minimal flags.
How do you do this properly?
Too much data going out one point, and it raises flags. Too much data moving between nodes that don't normally have connections to each other, alarms raised. Too much user account activity on nodes that don't normally have that - Alarms. Raised.
Modern SIEMs make it very difficult to create abnormal data traffic thanks to anomaly detection and heuristic analysis.
These systems are not perfect though, and the false sense of security they provide can actually be a pen testers advantage. Since people treat these systems as infallible, they rely heavily on the data provided and without them the analysts are nothing.
You have a few routes to get around this. You can masquerade your traffic as normal SMB traffic around the network, or even better, masquerade it as router traffic like RIP or OSPF. IDS systems are very careful not to intercept or mess with router communication.
Getting traffic out of the network is even harder. While it will be easier than initiating a connection from the outside in, since these will be blocked outright, it still raises a lot of flags watching a lot of different systems all of a sudden communicating with one server. I know from personal experience that a lot of data being transferred to outside the network will raise alarms. What you are looking for is to route traffic through one of the compromised nodes and out from there to the first stage of the C2 systems. Seeing multiple nodes communicating out to one cloud device will raise alarms. Seeing one node, specifically one that already does out of network communications, will raise less flags.
Creates a lot less traffic than:
These are inherent flaws in how logs are collected. If a device that normally does a lot of out of network communication is put on an IDS, it will generate a lot of alarms. These will be, over time, tuned out due to the amount of volume they create. Taking Target as an example. A flood of small alarms will hide more important ones, which can lead to systems being compromised if their alarms are not dealt with fast enough. A smart pen tester will abuse this tuning to try and find a high threshold of outbound traffic which doesn't trigger alarms. Smarter IDS will use machine learning and AI to take some of the manual work out of these alarms, but smaller operations generally can not afford these systems as of yet.
It's important to masquerade traffic leaving the system as something encrypted but simultaneously innocuous. Something to consider is DNS TXT records. You can host a server on a cloud compute platform that is set to respond to DNS requests. These TXT records can contain any variety of commands for your slaves to receive and generally IDS systems will not alarm on these. This makes it fairly easy to abuse. One thing to note is that the IDS might read the contents of the TXT response. I suggest XORng the commands or using some other kind of obfuscation so as to make it harder to determine what is in the responses to non authenticated eyes.
One more step is to create an election process within the compromised nodes, so that when one master goes down, another one is elected. Simplicity is better. The sky's the limits with what factors can go into this, but don't make it more complicated than it needs to be. Something like sending out probes to each node neighbors then seeing who gets the highest probe count would be adequate for considering who becomes the master node and who then gets to route traffic out to the C2 server.