{ "id": "b048fcc6-0bd3-4d2a-9503-f3628053e93f", "created_at": "2026-04-06T00:08:35.310625Z", "updated_at": "2026-04-10T13:12:35.171236Z", "deleted_at": null, "sha1_hash": "1930ee8b79c11d88b9fd28c6c335eaf08ff07026", "title": "DNS Over HTTPS for Cobalt Strike - Black Hills Information Security, Inc.", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 449150, "plain_text": "DNS Over HTTPS for Cobalt Strike - Black Hills Information\r\nSecurity, Inc.\r\nBy BHIS\r\nPublished: 2021-11-17 · Archived: 2026-04-05 13:05:14 UTC\r\nKyle Avery //\r\nIntroduction\r\nSetting up the C2 infrastructure for red team engagements has become more and more of a hassle in recent years.\r\nThis is a win for the security community because it means that vendors and professionals have learned from\r\npreviously successful techniques and implemented effective mitigations in their networks.\r\nDNS over HTTPS is an underappreciated channel for command and control. This blog will show you how to\r\nutilize DoH with Cobalt Strike in a way that requires no third-party accounts or infrastructure setup, encrypts\r\ntraffic with a valid SSL certificate, and sends traffic to reputable domain names.\r\nExisting Techniques\r\nAttackers and offensive security professionals have been using different redirector implementations for some time.\r\nThe first redirectors that I used were simple Apache and Nginx servers configured with various rules to forward\r\ntraffic based on predefined criteria.\r\nRedirectors are great for making infrastructure more resilient, but they can also bypass defenses that rely on\r\ndomain categorization. For example, once Content Delivery Networks (CDN) became more accessible to\r\nhttps://www.blackhillsinfosec.com/dns-over-https-for-cobalt-strike/\r\nPage 1 of 6\n\ndevelopers, attackers moved from traditional redirectors to these platforms because they often provide a valid\r\ndomain name and even SSL certificate to the user, reducing the work of an attacker.\r\nA technique known as “domain fronting” was later discovered and used heavily by many testers. More recently,\r\nhowever, CDN providers have been cracking down on this behavior. Many sites prevent domain fronting entirely\r\nor actively search for those using it. Microsoft in particular has been known to shut down Azure Subscriptions in\r\nthe middle of our operations.\r\nI have recently turned to other cloud services such as Azure App Services and Cloudflare Workers for traffic\r\nredirection. These have the same benefits as traditional CDNs but are less heavily monitored. While these services\r\nwork well, cloud providers could decide to start watching these with the same dedication as they watch CDNs any\r\nday.\r\nDNS over HTTPS\r\nTraditional DNS Beacons are relatively straightforward to detect. I have never used the Cobalt Strike DNS listener\r\non an operation, limiting me to the previously described HTTPS listener and redirectors.\r\nDNS over HTTPS for Beacon provides us reputable domains and valid SSL certificates without needing an\r\naccount or any configuration of the redirector. This reduces an operator’s setup time even further and eliminates\r\nthe risk of account shutdown.\r\nToday’s Topic: DNS over HTTPS for Cobalt Strike\r\nThe use of DNS over HTTPS was first presented to me on Twitter by Austin Hudson. His tweets over the last year\r\ndetailed his progress towards this capability and resulted in an open-source tool: TitanLdr. This Cobalt Strike user\r\ndefined reflective loader (UDRL) hooks the Cobalt Strike Beacon’s import address table (IAT) to replace the API\r\ncall responsible for making traditional DNS queries (DNSQuery_A) with a function that makes DoH requests to\r\ndns.google (8.8.8.8 and 8.8.4.4).\r\nThis alone is an excellent capability, but TitanLdr’s DNSQuery_A hook is generic enough to work with many\r\ndifferent DoH servers! I have tested the following domains and confirmed that they work as drop-in replacements:\r\ndns.quad9.net\r\nmozilla.cloudflare-dns.com\r\ncloudflare-dns.com\r\ndoh.opendns.com\r\nordns.he.net\r\nUsing TitanLdr\r\nTitanLdr is the key to integrating this capability into Cobalt Strike. You can grab the original TitanLdr, which\r\nbeacons to a single DNS provider over HTTPS server here: https://github.com/secidiot/TitanLdr. You can change\r\nthe DNS server on line 111 of the DnsQuery_A.c file in the hooks directory.\r\nhttps://www.blackhillsinfosec.com/dns-over-https-for-cobalt-strike/\r\nPage 2 of 6\n\nLine 111 in TitanLdr/hooks/DnsQuery_A.c (Original Repository)\r\nI have since forked TitanLdr to allow for multiple DoH servers to be specified. Each time a callback is made, the\r\nBeacon will randomly select one from a hardcoded list. If you want to use multiple DoH servers, you can\r\ndownload my fork here: https://github.com/kyleavery/TitanLdr. You can modify the list of servers at line 116 of\r\nthe DnsQuery_A.c file in the hooks directory.\r\nLine 116 in TitanLdr/hooks/DnsQuery_A.c (Forked Repository)\r\nOnce downloaded, you will have to build the program. This will require a Linux host with NASM and MinGW\r\ninstalled. Once you have these programs, run the make command to create the necessary files.\r\nBuilding TitanLdr\r\nImport the Titan.cna Aggressor script into Cobalt Strike, and you are ready to use DoH! Configure a DNS listener\r\nas you usually would. The Cobalt Strike documentation goes more in-depth on configuring this listener.\r\nhttps://www.blackhillsinfosec.com/dns-over-https-for-cobalt-strike/\r\nPage 3 of 6\n\nConfiguring a DNS Listener\r\nOnce the Beacon is running, we can see that only one DNS request is made to resolve the DoH server address.\r\nAfterward, all of the traffic is encrypted HTTPS.\r\nDoH Beacon Network Traffic\r\nDrawbacks of DNS over HTTPS\r\nWe’ve already discussed the benefits a DNS over HTTPS Beacon has over a traditional HTTPS Beacon, but there\r\nare also some definite drawbacks.\r\nFirst, more packets are needed to communicate the same information back to the team server. A DNS TXT record\r\ncan only contain a maximum of 255 characters, meaning we can only send a small amount of data in each packet.\r\nSecond, we have no control over the path or domain names of available servers. It seems easier for an\r\nenvironment or appliance to deny outbound 443/TCP to the list of popular or known DoH servers than block\r\nMicrosoft’s *.azurewebsites.net or Cloudflare’s *.workers.dev. You could solve this by using more obscure DoH\r\nservers or by building your own and categorizing them over time, depending on how the environment is\r\nconfigured.\r\nhttps://www.blackhillsinfosec.com/dns-over-https-for-cobalt-strike/\r\nPage 4 of 6\n\nPotential Detection Methods\r\nCurrent detection techniques may have gaps when it comes to detecting DNS over HTTPS.\r\nCurrent detections targeting malicious HTTPS traffic typically utilize domain reputation, rendering them\r\npotentially ineffective against DoH since the domains in use are reputable.\r\nCurrent detections targeting malicious DNS traffic typically monitor for many DNS requests, rendering\r\nthem potentially ineffective against DoH since the traffic is no longer using the DNS protocol.\r\nA combination of traditional DNS monitoring and SSL inspection could be a potential solution, but I do not know\r\nof any current tools or products that do this.\r\nMy understanding is that the primary defense against this attack is blocking outbound 443/TCP to known DoH\r\nservers that an organization is not using. Most networks I encounter still use traditional DNS, often with a local\r\nDNS server running as part of the Active Directory environment. In this case, there is no need to allow HTTPS\r\ntraffic to dns.google, cloudflare-dns.com, or any others mentioned in this post.\r\nClosing Thoughts\r\nThere are absolutely more DNS over HTTPS servers that could be used with this configuration. In addition, the\r\nuser could set up their own DoH server, maybe even behind a CDN or other cloud service, to introduce a variation\r\non this technique.\r\nTitanLdr is limited to Cobalt Strike, but the DoH implementation could be ported to any other C2 framework.\r\nThis method will not be the best in every scenario, but it is another tool in the toolkit that I hope you can take\r\nadvantage of. Feel free to contact me with any questions or comments on Twitter @kyleavery_.\r\nCredits\r\nThe idea to use DNS over HTTPS for C2 comes from the work of Austin Hudson. This technique and blog\r\nwould not have happened without his TitanLdr project. Austin’s code and tweets have inspired many of my\r\npersonal projects; I highly recommend following him.\r\nI mentioned that I currently use two redirector services for traditional HTTPS Beacons: Azure App\r\nServices and Cloudflare Workers. I originally discovered these techniques at the following two links:\r\nhttps://ajpc500.github.io/c2/Using-CloudFlare-Workers-as-Redirectors/\r\nhttps://github.com/bashexplode/cs2webconfig\r\nReady to learn more?\r\nLevel up your skills with affordable classes from Antisyphon!\r\nPay-Forward-What-You-Can Training\r\nAvailable live/virtual and on-demand\r\nhttps://www.blackhillsinfosec.com/dns-over-https-for-cobalt-strike/\r\nPage 5 of 6\n\nSource: https://www.blackhillsinfosec.com/dns-over-https-for-cobalt-strike/\r\nhttps://www.blackhillsinfosec.com/dns-over-https-for-cobalt-strike/\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://www.blackhillsinfosec.com/dns-over-https-for-cobalt-strike/" ], "report_names": [ "dns-over-https-for-cobalt-strike" ], "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": 1775434115, "ts_updated_at": 1775826755, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/1930ee8b79c11d88b9fd28c6c335eaf08ff07026.pdf", "text": "https://archive.orkl.eu/1930ee8b79c11d88b9fd28c6c335eaf08ff07026.txt", "img": "https://archive.orkl.eu/1930ee8b79c11d88b9fd28c6c335eaf08ff07026.jpg" } }