↓ Skip to main content
Taha’s
Taha’s
Blog ·
·728 words·4 mins· loading · loading

Domain Fronting - A Red Team perspective of Cloudflare

Masquerading the C2 traffic using Cloudflare.

Taha
Author
Taha
A persistent, self-taught and serious learner.
Table of Contents
Series Infra Kes7a 6 parts
  1. 01 Infra Kes7a - Red Team Infrastructure Overview
  2. 02 Picking Up The Correct Attack Scenario
  3. 03 Red Team Domain Names
  4. 04 Domain Fronting: A Red Teamer perspective of AWS Cloudfront
  5. 05 Domain Fronting - A Red Team perspective of Cloudflare You are here
  6. 06 Domain Fronting: A Red Team Perspective of GCP CDNs

Overview
#

The hard part isn’t about finding a vulnerability in the target assets, that, as a matter of fact, is very common and we’re pretty sure we will find some. But, maintaining that connection without getting caught by NDRs and blue teamer is challenging. So our C2 communications should look legit, logic and very well blend within the usual and common traffic sinffed by NDRs. In this post we’re aiming at hiding the outbound C2 traffic from the compromised host to our redirector (which will then forward it to our C2 if it matches the correct rules).

The idea is to get the implant to connect to our domain (which we already verified its categorization, legitemacy, name choice..etc) using valid SSL certificate from a known provider which will make the traffic look normal and wouldn’t trigger any alerts caused by custom certs.

For our case, we’ll use a full encryption between the implant, Cloudflare and the redirector, so not only between the client (the implant) and Cloudflare, but also between Cloudflare and the redirector. This will limit the firewall rules we put for our redirector, protects all the channel from both client and server side and ensures the tunnel cannot be decrypted.

cloudflare overview
Warning

Of course, the payload delivery isn’t coverred in this part. This is all about an opsec-complient post-exploitation persistence.
We assume we already have a foothold within the target network.

Cloudflare for DNS management
#

Switching to Cloudflare
#

First, we need to make cloudflare as our DNS management platform to proxy the connections to our domain via cloudflare nameservers. This could be done from whatever registrar your bought your domain from and it is pretyy much straightforward to acheive.

  1. Visit Cloudflare dashboard.
  2. Click on Add domain.
  3. Fill out the domain name field and the other Bots settings (Block all) and the free plan (of course).
  4. Cloudflare will give you the nameservers you’ll need to connect your domain to cloudflare’s proxies.
  5. Visit your registrar’s management page for your domain
  6. Go on the nameservers settings, delete the nameservers your find and add cloudflare ones.
  7. Now you can manage your domain’s DNS settings from Cloudflare dashboard, you’ll receive a mail from Clouflare as soon as it links.
  8. Wait for a couple a minutes for it to propagate properly, and you’re ready to go.

Testing
#

testing Nameservers
#

bash
$whois domain.tld  
$nslookup domain.tld
$dig ns domain.tld

Which will show Cloudlfare’s given nameservers.

Testing Propagation
#

Or visit DNS Checker to see the connectivity of your domain worldwide.

and our dns config should contain at least these entries (the * depends on your configuration, i removed the * later)

We’re good to go.

Cloudflare SSL/TLS overview: Flexible vs Full (strict) mode
#

Cloudflare offers many SSL/TLS configurations:

Flexible is a client-side configuration. It onyl encrypts incoming traffic and then sends it unencrypted to the redirector. That is the simplest configuration since it won’t cause any certificate issues. But that ain’t us.

We’ll aim at the Full (strict) mode and its description is self-explanatory.

For this, we will need to create a valid cloudflare certificate for the redirector, import it to Apache (or whatever redirector you chose) and go on.

Requesting a Cloudflare certificate
#

Go to the Origin Server on SSL/TLS section and request a certificate:

Choose the subdomains, the private key type and the duration you wish:

Now, SAFELY save these two files. They shouldn’t be shared or open-sourced or bad things will happen, surely.

and save them to:

  • /etc/ssl/certs/enit-kedux.pem
  • /etc/ssl/private/enit-kedux.key
Danger

SET THE PROPER PERMISSIONS ON THE PRIVATE KEY.

bash
sudo chmod 600 /etc/ssl/private/enit-kedux.key

Apache will then import them when restarted.

Click on Ok and you should be okay

About the certificate

Note that you can revoke or download your certificate for later use sharing with other infrastructure maintainers. The essential point is that you should always deal with it safely to not publicly leak it.

Import the cert to the redirector
#

Now we should point Apache to where the certificate is. For this we need to add these entries to its /etc/apache2/sites-available/redirector.conf

output
    <SNIP>
    ServerName domain.tld
    ServerAlias domain.tld

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/domain.pem
    SSLCertificateKeyFile /etc/ssl/private/domain.key
    <SNIP>

And /etc/apache2/ports.conf should look like the following:

bash
<IfModule ssl_module>
    Listen 443
</IfModule>

<IfModule mod_gnutls.c>
    Listen 443
</IfModule>

Now we should enable the SSL mode and restart Apache.

bash
sudo apache2ctl configtest
sudo a2enmod ssl
sudo systemctl restart apache2

Tests and Validation
#

Filed under
Cloudflare Domain-Fronting Red-Team C2-Infrastructure Evasion-Techniques Opsec Covert-Communication Network-Evasion Tls Dns Https Reverse-Proxy Apache Traffic-Obfuscation
Next in this series · Infra Kes7a 06 Domain Fronting: A Red Team Perspective of GCP CDNs

Related