Abusing native cloud services for Command and Control

Uh, first up we have Steven Bradshaw with abusing native cloud services for command and control. So please a round of applause for Stephen.

All right, thanks everyone. Um, I'm going to be talking about abusing native cloud services for command and control. So as an overview of what I'm going to be talking about today, I'll start off with a quick introduction to what control command and control actually is. Uh, sometimes shorten to C2, apologies. Uh then I'll talk about some problems you can run into with simple C2 designs and how you can actually fix these problems through the implementation of a concept known as the high reputation redirector. Finally, I'm going to talk about ways you can actually implement these high reputation redirectionctors with native services in AWS, Azure and GCP. So I'll be talking about other people's work and

my own work. So what is command and control? Command and control is a post exploitation activity. So it actually happens after an attacker has already compromised a victim host and then they use the command and control system to actually control that system after that point. C2 makes use of dedicated attack focused client server software and C2 needs to remain hidden in order to be effective because no one wants their machine controlled. So I mentioned that C2 needs to avoid detection. There's three main components to this. First of all, you need to hide the client or implant on the infected host. So, this involves um avoiding antivirus and EDR and avoiding attracting the users's attention. Second, you need to hide the

communication between the client on the infected host and the C2 server on the internet. So, this usually involves um using expected network traffic. So, uh network traffic that would normally kind of happen on that host. So some examples are using HTTP, so web browsing traffic, uh domain name resolution traffic or DNS, and sometimes custom protocols such as Slack or Discord. You also need to be able to deal with the ways in which this expected traffic might actually be kind of filtered or blocked. So for example, in corporate environments, you might actually have um filtering proxy servers that'll block uh traffic to domains that are kind of known bad. You have to deal with that. Finally, you need to hide the server on

the internet. And this is normally done by making that server look innocuous um with regard to whatever traffic it's pretending to receive. So, if it's if it's receiving HTTP traffic from infected uh clients, it needs to look more or less like a normal web server. And you want to avoid the server ending up on any block lists. So, I've mentioned that you can use a number of different communication protocols um to talk between the client and the server. I'm going to be talking in this talk about using HTTP and HTTPS. And there's a number of different reasons for this. First of all, HTTP is really commonly allowed and commonly used. So, commonly allowed in corporate

environments and commonly used because lots of people browse the web. It's very common traffic. Second, HTTP and HTTPS are really well supported in many commercial and open- source C2 software solutions. So, um, Mythic, Cobalt Strike, uh, Sliver, they all support it and they support it really well. Finally, HTTP gives you a lot of flexibility in how you can actually kind of design and architect your C2 system. So, there's lots of different third party bits of software that can do stuff with HTTP like proxy it, filter it, forward it, um, redirect it, etc. and it gives you a lot of additional options in how you can kind of architect your C2 infrastructure. So what we have here is pretty much the

simplest possible C2 architecture you can have for a C2 server on the internet uh talking HTTP. So the C2 server is up the top and it is listening for communication from implants uh at the domain www.evil.com. So nothing sus there. It's bound on port 80 and 443 for HTTP and HTTPS. And it is receiving traffic from one or more victim hosts over on the left that have been compromised that are being controlled by this C2 server. Over on the right, we have a separate channel that the attacker will actually use to control the C2 server. So, we won't be focusing on this too much in this talk. Just be aware that the admin talks to

the C2 server on a different channel than the compromised systems do, the compromised hosts. So, there's a couple of different issues with this simple design that we're going to go over in the next few slides. First of all, this implant address and the trustworthiness of it. Um, even if it wasn't called evil.com, the fact we designed this system new, we set up a new C2 bit of infrastructure for some particular campaign that we want to do. If we set up a new system, it needs a new address that it can be communicated to. And that new address has to be custom to the solution. And if it's new, it's going to be untrusted by default by

a lot of com domain reputation databases. So domain reputation databases normally work by making sure that a domain has been around for a while and it has been associated with good traffic before it considers it as trusted. If we instead tried to use a public IP address to communicate to this thing, we'd have a separate set of problems. First of all, direct HTTP communication to IP addresses is kind of rare and so it sus just because of this and also you're going to have challenges actually setting up HTTPS um with getting certificates for this. Next problem is exposure. So in this case the C2 server is basically directly bound to the internet on these two

different ports and the C2 server software itself is listening. So this means if there's any vulnerabilities in that software itself, they're more directly exploitable. So there's nothing in the way. There's nothing kind of filtering traffic to that to those ports. And also it means it's more fingerprintable and more detectable through scans over the internet. Uh and there's techniques such as JAM which look at kind of unique characteristics of how TLS negotiation is done that can actually be used to detect C2 servers that are directly connected to the internet. And there's a slide or there's a link to uh some information about jam if you're interested and I will share these slides afterwards. So don't feel

you have to kind of remember these um links I'm going to show. Final problem is there's no separation between this implant endpoint and the C2 server itself. So that endpoint gets burned. So the domain evil.com raises someone suspicious and it gets burned. The whole infrastructure has to go. So there's no separation between the implant endpoint and the whole infrastructure. So one goes the whole lot goes. So how can we solve some of these issues? So the common solution that is used when people design C2 systems to actually resolve these issues is the use of a high reputation redirector. A redirectionctor itself is basically just a service that takes in traffic on a protocol in this case HTTP and sends it

to a backend server. So essentially it acts as middleware and forwards traffic between the two points. A high reputation redirector is one that has a good like a a domain associated with it that has a good reputation because most of the use of the service is kind of legitimate and good. And basically what you're doing if you're using one of these services is you're basically hiding your bad traffic within hopefully an overwhelming amount of good. The concept was first discussed to my knowledge on the cobalt strike blog and there's a link and a and a kind of overview of the the post on the slide here. This was posted back in early 2017. So the concept has been kind of

known in kind of C2 design circles for quite a while now. So here is a modified architecture diagram where we're actually using one of these high reputation redirectors. So in this case, what we're using is a CloudFront distribution and instead of connecting to evil.com, our victim hosts are now connecting to bunch of random characters. Cloudfront.net. So this design solve a lot of the kind of different problems that we can run into that I just mentioned with C2 designs that are too simple. So we've got some separation. we've got a more trusted address and we can actually replace that CloudFront distribution with some other with with another CloudFront distribution or another different approach if we want to and

there's no reason why we can't have multiple of these kind of redirections in place at the same time. So one Z2 server can kind of receive connections from multiple different redirected kind of um redirectionctors. So now that we've explained the concept of what these redirectionctors are, what characteristics about a service like CloudFront that we looked at make it a good candidate to be used in this way? So we'll define the goal as achieving functional HTTP and HTTPS communications for unmodified C2 software. So we don't want to have to modify our C2 software to actually make it work with one of these services. We want to be able to just kind of plug and play. you know,

any C2 software that we want that works with HTTP along with any red, one or more of them. So, there's a number of different criteria that I've identified. First of all, and hopefully pretty obviously, the service has to do redirection of HTTP traffic. So, you have to be able to receive HTTP traffic on your address and send it to a backend of your choosing. So, you need to be able to configure that back end. And there's a number of different types of services that work for this, which we'll go into more detail later. In addition, we want to get a trusted DNS domain associated with this service. So, we don't want to have to. So, a

number of these services do allow you to bring your own domain, provide your own domain to be used with them, but we want to actually take advantage of some domain that actually has high trust associated with it. So, we don't have to kind of worry about aging our own domain. And optionally we also want the whole setup to give us HTTPS and a trusted SSL certificate. The services also need to support in terms of HD methods at least get and post. They need to support binary content in the message body. They need to have they need to be able to have caching disabled. So you need to be able to turn it off if it's enabled. And they

need to retain any cookies set by the backend server. They also need to maintain the URL path and query parameters as is. So whatever the client sends in terms of URL path and query parameters, they need to go directly through to the back end unmodified. Um it is possible and it is and it can be allowed to have uh consistent characters at the start of the path like forward/ API, but it just can't modify it. So now that we've explained the concept, we're going to have a look at a bunch of different work um in which various cloud services are actually kind of used for this. Um so we'll we'll we'll kind of identify which cloud services can be

used for this. So we'll look at um prior work and we'll look at my own testing and investigation. Okay. So here's a number of different posts talking about services in AWS that work for this. So we've got one about Cloudron which we've already discussed. We've got a post talking about AWS API gateway forwarding to a Lambda and we've got a post about an AWS function URL sending to a Lambda. So these posts are from 2019, 2020, and 2022. And these are the three that actually got me interested in this topic. And all of these approaches still actually work today with some minor modifications in how you actually have to implement it because the services continually change

and update. Here are a couple of posts talking about Azure services that work for this. So we've got one talking about Azure function apps, which still works today. We've got a kind of combination post which talks about a number of different services including an Azure CDN that doesn't exist anymore from 2023. So this is a fastmoving field. Um even things from a few years ago may not work anymore. You've got to continually kind of um check and verify that everything is working if you want to try one of these approaches. And then finally we've got a post talking about Azure static web apps. Now this um you'll notice I've got Tim Robinson next to that um that

post um with a is you sure about that? Um the reason why I've done that uh this approach actually involves doing a client side redirect. So it doesn't actually hide the backend C2 very well. So I wouldn't recommend this approach. I'm not trying to rubbish that guy's work or anything like that. I'm just saying that that that was an oversight that he didn't actually mention. Finally GCP. Uh, this service or this cloud provider doesn't actually get a lot of attention in this area, and maybe that's good for them. I don't know. Um, but we've got this one post that I could find talking about using Google App Engine. Um, the impressive thing was, uh, this was

written really early before this concept was really kind of popularized. So, back in early 2017 and actually before that Cobalt Strike blog post that I talked about earlier. And this service still works today. So I've mentioned that this is a fast kind of moving field. Um what approaches actually still work now? So over the last 6 months or so I've verified a number of different approaches um working for AWS, Azure and GCP that work for cloud um the redirection of C2. Now there's a lot of services to go over here. So I'm going to be going over them in fairly high level of detail. So I'll discuss them by category and talk about what that category of services kind of

is and how it works. I'll talk about the different domains that are available that the the cloud provider domains that are high trusted that you actually get access to when you use these services. And I'll talk about whether the service automatically gives you HTTPS set up for you. And I'll talk about any kind of unique quirks. And I'll also share these slides afterwards uh so you don't feel you have to remember anything. So the first category is VM instance domain names. And this is my least favorite category, but I mention it because it does work. So in the case of AWS and Azure, if you create a VM and you give that VM a publicly addressable

IP address, you can also get a cloud provided domain name associated with that IP address. And this allows you to essentially set up a proxy on that VM that can forward traffic to your backend C2. So you've get trusted domain nodes which are listed on the slide. Uh in the case of the EC2 instance, it kind of looks like an EC2 instance. So it basically starts with EC2 and has the IP address. So it's not really going to fool anyone who looks at it kind of manually as to what it is, but it is trusted by a lot of domain reputation databases. So it is useful. Um Azure is a little bit better. You get something

that uh where you can choose the start of the the name. So your chosen label and it's a region and then cloud app. got ajour.com. So it looks more like an app. In this case, if you choose this approach, you basically have to set everything up yourself. So if you want HTTPS, you have to get a certificate. So you can do this for free using Let's Encrypt for either of those different domains. You have to set up the proxying configuration yourself. So you can do it with a custom tool or you can use Apache or you can use engine X. Um this approach is not my favorite. It kind of involves too much clients. there's too

much kind of OS level configuration and it's not I don't know doesn't have as much cool factor as some of the other approaches. The next category is content delivery networks and these are basically um networks that kind of make your website kind of more globally available by having points of presence all over the world. In the case of AWS and Azure, so CloudFront and Front Door, you can get one of these um distribution networks set up and get access to a cloud provider domain name. So it's um random characters.cloudfront.net for um CloudFront and your label-random and then a number of different subdomains. FD.NET for front door. um you do get HTTPS set up for you if

you use this approach. You do need to make sure you turn off caching because these things are designed to cache and cing is going to break any C2 servers. Now I will mention that GCP also has a CDN but you don't actually get a cloud provider domain name associated with that. If you set one of those distributions up you can only bring your own custom domain name. So I haven't listed it here. Next is API services. So these are different services that make it easy for you to basically launch a HTTP API on the internet. Make it internet accessible and make it accessible at a cloud provider domain name with HTTPS included. So there's AWS API gateway, Azure API

management service and GCP API gateway. Now in the case of the AWS API gateway, you've got two options in what you can send it to in the back end. So you can either trigger a lambda which is surplus code and we'll be talking about that later or you can directly proxy to a backend HTTP service. Uh and in the case of Azure API management service and GCP the configuration is probably a little bit trickier than API gateway. So you basically have to set up a custom either open API or swagger um kind of API definition that forwards all traffic. And it's it's not well documented, at least not for this use case, but and it

took me several days to work out how to do for each of them, but I've documented it and I'll share the links later. Next is manage website services. So for AWS, amplify and elastic beantoalk are basically services that make it easier to launch websites on the internet and they basically um the websites are provided a cloud provider domain name. You get HTTPS automatically if you use amplify. You have to set it up yourself for elastic beantoalk and the websites can basically be in the case of amplify it's basically just you can set up a configuration that just forwards traffic somewhere else in the case of elastic beantoalk you can use a custom app that will just forward traffic for you so a

custom python app next category is container execution services these are essentially services that make it easy for you to run a container like a docker container on the internet and make it accessible to web traffic at again a cloud provider domain name. So the services are AWS apprunner, Azure container applications and GCP cloud run. You get HTTPS for all of these set up for you. Uh cloud run is a special case here in that it can run either a container or it can run serverless code. So essentially you if you provided a container it'll run that. If you provide it code it'll wrap it in a container for you and then run that container. Finally, we have serverless code

execution. And these are essentially services that take a bit of code that you provide and it wraps it in kind of lightweight infrastructure like normally a lightweight VM or a container and then it runs it on the internet and makes it accessible at a cloud provider domain name again. So there's a number of different services AWS Lambda, Azure function apps and GCP cloudr run, Google app engine and cloud run functions. Uh now the domain name that I've shown on the slide here is the function URL one. Um the lambda as I mentioned earlier can also be accessed or fronted by an API gateway. So in that case the domain used would be the one for the API

gateway. Um and you get SSL certificates and HTTPS included for all of these different approaches. So here I've just got slides listing all of the different services by provider for later reference. So I won't read them all out but there's seven AWS ones. There's four Azure ones and four GCP ones. Now, I've gone through that fairly quickly because of the amount of information. If you want more information, you can actually go to that link there on my blog. And I've got probably about 12 different posts going back to 2023 talking about how to set up each of these different approaches in detail. So, you can actually proof of concept it yourself if you're interested. And I'll share these slides later as

well. Finally, let's just talk about the legal stuff at a very high level. Um, AWS, Azure, and GCP all have terms of service that you agree to when you use those services. Uh, the Azure and GCP terms of service don't mention running C2 that I could find. AWS actually require that you submit a simulated events form if you want to run C2 and then you'll generally get permission for about 90 days to run it. All of the providers don't want you doing anything illegal. And if you're any way concerned, get your own legal advice before doing this. And that is everything.

Thank you, Steven. Uh, do we have any questions for Steven?

go to the front first and then there's one. >> Thank you very much. The uh so the basically you can go to uh uh these pro providers and just get a um get these services like um they don't they're not interested in monitoring what uh their customers are doing. I'm assuming they do do monitoring, but they haven't. Well, I would say if you get an abuse report, you're going to have a problem. >> Yeah. >> But I don't think I haven't seen any sign that they actively monitor for this type of use. I would say the vast vast vast majority of use of these services is legitimate. Uh and I think like no one else other than me has discussed

using a lot of these services in this way to my knowledge. >> Um so other than the ones I actually mentioned in the prior work section. So I don't think they're carefully looking for it. >> Thanks. I'll read your blog. >> Okay. >> Thank you for presentation. >> Um, we've also seen some of the uh uh hackers are using GitHub or uh various uh chat platform uh or uh content publishing platform to uh as a uh C2 um server. Um and from the uh Vault 7 leak um we also see uh stagnography. So uh what would they uh how would we uh approach in um for example next generation uh next generation firewall to defend a more and more sophisticated

uh C2 or yeah communication. Thank you. So, um, if I'm understanding your question right, you're asking how would you defend against some of this kind of hiding of C2 traffic and detecting it with a nextG firewall. Is that right? I mean, this is a constant arms race. Um, attackers obviously don't want their C2 traffic identified. Um, and defenders want to identify it. So, uh, there's going to be constant kind of, you know, when one approach is detected, the attackers are going to change it. It's it's a constant arms race. I don't know if there's any kind of generic approach that would kind of work, you know, foolproof forever. Like it's, you know, you know, it's a whack-a-ole basically.

>> There one more question in the middle here.

>> Hi, uh, thank you very much for the great presentation. Did you actually explore uh another cloud providers like um I don't know Oracle, Alibaba or IBM maybe um if they would have like the similar kind of services can be used for same purposes. >> I haven't yet that's a potential kind of future project. Yeah, just those three was enough to start with. >> Are there any more questions? That case please a round of applause for Stephen.