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:
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:
https://github.com/bluscreenofjeff/Red-Team-Infrastructure-Wiki
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
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 (http://securityaffairs.co/wordpress/38978/cyber-crime/apt-29-report.html) 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:
https://github.com/bluscreenofjeff/Red-Team-Infrastructure-Wiki
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