This afternoon, while mountain biking, I was listening to a cybersecurity podcast about botnets. The gentleman on the episode was discussing detection of unknown botnets by looking at recurring patterns from the level of a dynamic DNS provider. A provider like this has incredible insight into web traffic on a global scale. The man described observing synchronized events of large numbers of distributed endpoints checking in with their Command and Control server (C2). He used DNS to sinkhole C2 communications traffic from the endpoints. Instantly my mind wandered back to seeing the recurring malicious events I had seen days prior in Azure sign-in logs.
The malicious authentication attempts, while unlikely to have been generated by a botnet, demonstrated clear and obvious patterns that are easily recognizable by humans. A signature is easily developed and used to block such recurrent events.
However, it occurred to me that if one were attempting to obscure such events, they should distribute the desired mean time of occurrence to their endpoint clients along with a desired delta range (which could also correspond with action urgency). Then, on the client side, allow for a pseudo-randomized delta within the C2-provided parameter to be locally generated for determining actual client event execution time. This technique could be instrumental in the obfuscation of a given event, as the actual event occurrence time for any given client would be randomized.
This concept extrapolates quite nicely to the distribution of C2 servers as well. An entity could establish their C2 by mirroring the server across several dozen relay nodes across different domains. The endpoint clients could have provisions to make a pseudo-random selection of a relay node to communicate with for a timeframe that has been randomized within a specified parameter as well. Using the above method to generate event randomness, communications with a randomly selected C2 relay node would be extremely difficult to detect by humans.
Savvy readers may notice the conceptual resemblance to TOR network, with relay nodes and random selection taking place.
Update: as I have continued in my studies, I’ve found that these concepts are already integrated into the malleable options within Cobalt Strike beacons. This is referred to as “jitter,” and is specified as a percentage value. Palo Alto Networks has released an article titled, “How Malleable C2 Profiles Make Cobalt Strike Difficult to Detect,” detailing the subject, and it would appear that my thoughts are correct- this technique can prove highly effective in obscuring C2 communications.