Skip to main content

Thoughts on C2 Designs and Tradecraft

Howdy folks!

This post is basically me trying to get out some thoughts regarding design concepts for command and control infrastructures. As a red operator who is also responsible for managing our teams infra, this is one of my favourite topics.

I'm also currently working on a talk that I will be shopping around in 2018 on this very topic so I'm using this blog platform as one more tool to collect ideas and work out what will probably end up in the talk.

I want to start off by mentioning something that a wise man said to me recently when I posted the following question on Twitter:

Justin "@sixdub" Warner, someone I greatly respect, said:

Whether you agree or not, I think it's a valid point worth some thought. Red teams and the infosec community in general do very much like to push the envelope in ideas, complexity, tradecraft and the like. Threat actors do the same. A question I like to ask myself from time to time is, "Do offensive tactics and strategy drive the innovation of defence or does defensive tactics and strategy drive the innovation for attacks?" I don't have an answer but I do enjoy the debate up in my head.

When I'm thinking about designing a C2 for an operation, I like to consider a lot of variables such as:
  • Scale - how many assets do we really need. More isn't necessarily better. Less can limit our options. How many operators are involved? How much access do they need?
  • Maturity - how 'sophisticated' do we need to appear and what level of defence does our client have in place.
  • OPSEC - Similar to the maturity question, how much of our infra should I expect to be burned, what will I need to roll quickly? How much do I need to make the blue team/investigators life hard. 
  • Goals - Similar to the scale question, what is going to allow us to accomplish our objective in the least amount of effort?
  • Replication - What am I trying to 'appear' as? Do we need to tool up in-house for the whole thing? Is Cobalt Strike or Empire etc. providing adequate capabilities? Are we going to run a MITRE ATT&CK playbook? Emulate APT241?
The list goes on and on but I'm sure you get the idea.

For red (and equally for blue in my opinion) threat intel is critical. I LOVE reading threat intel reports, debating findings with my friends and testing out those ideas in the lab. Why does this matter? Well I think it's super important for red folks to be up to date and current on what actors are actually doing out there. Like Justin Warner said, you won't always see actors in the wild going to the lengths that some red teams may go to such as leveraging domain fronting (give it time ;) ) but that's no reason to look down on a campaign that appears basic. Did it get the job done for the adversary? If so then that's kind of all that matters within that context.

One area that adversaries have taken advantage of quite often is 3rd party services such as Twitter, Google, Github and more. I really like this approach and as more and more services pop up and offer API access I can't imagine seeing this strategy going away. 

In the original question I asked on Twitter, APT29 definitely got a lot of attention in the thread. Below is a screenshot from Security Affairs ( showing a graphic of the chain used by APT29 for Hammertoss:

I always liked this example because it breaks free from the 'traditional' C2 that can become commonplace for pentesters such as the single operator connecting to a single cloud instance of Kali Linux with nothing in between them and the target. Don't get me wrong, if that gets the job done for you then awesome. However, when it comes to a requirement for more long term operations, more complex tooling and capabilities and especially a skilled defensive team, that setup will get crushed lickity split.

Another very smart individual I give great respect to and has influenced my knowledge in major ways is Jeff '@bluscreenofjeff' Dimmock. If you haven't seen this resource yet I highly recommend you do:

It's a treasure trove of knowledge regarding red team infra design concepts and considerations when planning your operations. There's even a mentioned resource in there from yours truly! (and yes, I'll be writing my part 2 very very shortly....I know, I'm just being lazy.)

Offensive infra design is so fascinating to me because aside from some of the basic requirements there is a lot of wiggle room for creativity. If you are responsible for standing it up and managing the infra, it becomes a sort of canvas for you to paint and create your masterpiece. You can have opportunities to provide your ops people to do some creative things, have your dev folks tool up some neat features to add, play the awesome game of whack-a-mole with the target as they try to take you down, so on and so forth.

I think I'm going to wrap it up here but I will certainly be putting a lot of effort into the talk I'll be hoping to present throughout 2018 and will add some new posts in the new year about the various approaches and technical implementations of C2 design.

Thank you so much for reading and happy hacking :)

- @InvokeThreatGuy

Popular posts from this blog

Leveraging WEF and the HELK

In an effort to have some more content on this blog (wow life gets busy sometimes!) I thought I'd write up this post on how to configure Windows Event Forwarding and the awesome project, HELK. On a bit of a side-note, this post coincides with an event we run up here in Toronto, Canada called the Canadian Collegiate Cyber Exercise (C3X). This year we are running the first real iteration (although we executed a pilot version last year which you can see here: ) and part of the design will be providing the students with HELK. OK back on track. I'll admit that when I first learned about Windows Event Forwarding it seemed a little daunting. A few of the posts I first read seemed confusing and a lot of moving parts. To the newcomer, Windows Event Logs can also be fairly intimidating which is why projects such as HELK are so fantastic to be openly and freely distributed. So why leverage WEF? Well, at a very basic level (and this

We Break So We Can Build Better

Hello again friends! Today I'm writing this post to shed a little preview light on how our team that builds C3X (Canadian Collegiate Cyber Exercise) will be approaching the design for the 2019 competition. We are doing a lot of different and fun things this year which means all of us are very excited and at the same time have a beast of a project ahead of us. I'm also going to discuss areas where you can help out and be a part of this wonderful event. C3X Overview Entering its third year, the C3X is a competition that puts student teams from various Canadian colleges and universities who are enrolled in cyber security programs a chance to defend a controlled environment against a team of offensive security professionals. That's the short and sweet version but there is so much more. Ben Wells (@1StealthMove) and I created this in 2016 and saw the first event happen in 2017. Why did we do this? Canada isn't exactly overflowing with combative challenges. Sur

Simple PowerShell One-Liners

In this post, I want to go over some basic recon-style commands in PowerShell, which complements a talk I gave recently at the DefCon 416 meetup. A good chunk of my demonstration consisted of various ways to accomplish simple recon and post-exploitation tasks by leveraging what is already installed throughout Windows environments. I'm going to keep things very basic and simple just in case PowerShell is brand new to you. These "one-liners" are meant to show things you can incorporate into a script that, when placed onto a targeted machine, executed in memory, can spit the output into a file or send it back to a C2 server. Let's begin :) I am using a Windows 7 virtual machine running PowerShell v2, but feel free to use Win8 or higher. Open up a PowerShell prompt (no need to run as an admin, but may be required later).   I create a folder on the desktop called "hello" with a single text file called "hello.txt" inside. Feel free to do the