Domain Fronting Attacks were on of the top 5 attacks listed in material that came out of the RSA 2019 Conference as a way for attackers to obfuscate their activities. This was of high interest to me, so I dug in.
Formally, Domain Fronting is a technique leveraged by threat actors to use high reputation domains to disguise C2 callbacks from both the user and security tool sets.
Domain Fronting attacks work in Cloud Distribution Networks, (CDNs). CDNs are leveraged by companies who want to put themselves ‘closer’ to the customer and thus will allow the CDN to cache specific elements of the application on CDN owned Points of Presence(POPs) that are geographically close to the customer base. To do this, the CDN will also host the SSL Web Certificate of the Domain. This is where we get started.
1. Attacker sets up their own server on the same CDN as the target company, (the target company is the company whose legitimate SSL Certificate is intended to disguise callbacks to the attacker’s C2 network). For an example, let’s say the legitimate domain with a SSL cert is Henson.com hosted on a CDN. Attackers server is on the same CDN.
2. Initial Malware callback to legitimate domain. Attacker’s malware that is resident on any internal corporate network(that got there via phishing / or other means), makes its initial callback. However, the callback does not go to attacker owned domain, instead the callback goes to the a legitimate domain, Henson.com, hosted on the CDN. This step simply sets up TLS session between Malware endpoint and Henson.com property on the CDN.
3. User and Security Tools are fooled. The DNS resolution and the following call looks like any other web call to a legitimate domain, and the browser trusts the certificate.
4. Malware makes a second call to the attacker owned resource in the same CDN as Henson.com, hidden via the http 1.1 host header inside the valid TLS connection.
5. Request is routed. CDN fronts this second request as it is for Henson.com, but next it unwraps the TLS header, it reads the http 1.1 host header and re-routes request to the attacker’s server on the CDN.
6. Another Re-direct. The attacker, not wanting their activity to be discovered by the CDN, simply has their server in the CDN do a second re-direct to an off-CDN command and control server anywhere in the world. From the CDN point of view, Nothing nefarious there, just a redirect . . .
7. The Command and Control Channel is set up. At this point, the redirect to the off-CDN command and control completes, so the full C2 is set up:
Infected Host inside corp network -> CDN -> Henson.com on CDN -> Attacker's re-direct server on CDN > Attacker C2. and completely hidden.
Defending Against Domain Fronting
As a Security Defender, your best defense against Domain Fronting is to have a proxy server for all your internet connections leaving your corporate network that is configured for TLS interception. You can configure your proxy server to ensure the http 1.1 host header matches the domain that is in the URL. If the domain does not match, you can overwrite it, log (and alert) on the action.
Another defense technique to think about is to ensure you don’t have any dangling DNS / CDN fronted resources that the CDN would route to an origin host that is no longer present.
Also, taking several steps back, it was assumed that malware was present; and was making a callback. Strong host security, code signing, and application white listing can help prevent malware from running in the first place.
Stay safe, friends!