DNS over HTTPS (DoH) was introduced to increase privacy and help prevent against the manipulation of DNS data by utilising HTTPS to encrypt it. Mozilla and Google have been testing versions of DoH since June 2018, and have already begun to roll it out to end-users via their browsers, Firefox, Mozilla, and Chrome. With the adoption rates of DoH increasing, and the fact that C2 frameworks using DoH have been available since October 2018, DoH has become an area of interest for defenders; one C2 that stands out is goDoH by SensePost (https://github.com/sensepost/goDoH).
goDoH is a proof of concept Command and Control framework written in Golang that uses DNS-over-HTTPS as a transport medium. Currently supported providers include Google and Cloudflare, but it also contains the ability to use traditional DNS.
The Attack
With goDoH, the same binary is used for the C2 server, and the agent that will connect back to it. In the screenshot below, I am setting up the C2 on a Windows endpoint - I specify the domain I will be using, the provider to use for DoH, and that this is the C2:
On the victim endpoint I do the same, but instead specify that this is the agent:
After a short period of time, our successful connection is made, and we can begin to execute our reconnaissance commands:
RSA NetWitness Platform Network Analysis: SSL Traffic
Given its default implementation using SSL, there is not a vast amount of information we can extract, however, that does not mean that we cannot locate DoH in our networks. A great starting point is to look at who currently provides DoH - after some Googling I came across a list of DoH providers on the following GitHub page:
These providers could be converted into an application rule (or Feed) to tag them in your environment, or utilised in a query to retroactively view DoH usage in your environment. This would help defenders to initially pinpoint DoH usage:
alias.host ends 'dns.adguard.com','dns.google','cloudflare-dns.com','dns.quad9.net','doh.opendns.com','doh.cleanbrowsing.org','doh.xfinity.com','dohdot.coxlab.net','dns.nextdns.io','dns.dnsoverhttps.net','doh.crypto.sx','doh.powerdns.org','doh-fi.blahdns.com','dns.dns-over-https.com','doh.securedns.eu','dns.rubyfish.cn','doh-2.seby.io','doh.captnemo.in','doh.tiar.app','doh.dns.sb','rdns.faelix.net','doh.li','doh.armadillodns.net','jp.tiar.app','doh.42l.fr','dns.hostux.net','dns.aa.net.uk','jcdns.fun','dns.twnic.tw','example.doh.blockerdns.com','dns.digitale-gesellschaft.ch'
NOTE: This is by no means a definitive list of DoH providers. You can use the above as a base, but should collate your own.
Running this query through my lab, I can see there is indeed some DoH activity for the Cloudflare provider:
As this traffic is encrypted, it is difficult to ascertain whether or not it is malicious, but there are a couple of factors that may help us. Firstly, we could reduce the meta values to a more manageable amount by filtering on long connection, which is under the Session Analysis meta key, this is because C2 communications over DoH would typically be long lived:
We could then run the JA3 hash values through a lookup tool to identify any outliers (in this instance I am left with one due to my lab not capturing a lot of data):
For details on how to enable JA3 hashes in the RSA NetWitness Platform, take a look at one of our previous posts: https://community.rsa.com/community/products/netwitness/blog/2019/12/02/using-rsa-netwitness-to-detect-command-and-control-poshc2-v50
Running the JA3 hash (706ea0b1920182287146b195ad4279a6) through OSINT (https://ja3er.com/form), we get results back for this being Go-http-client/1.1, this is because the goDoH application is written in Golang - this stands out as an outlier and the source of this traffic would be a machine to perform further analysis on:
RSA NetWitness Platform Network Analysis: SSL Intercepted Traffic
Detecting DoH when SSL interception is in place becomes far easier. DoH requests for Cloudflare, for example
, supply a Content-Type header that allows us to easily identify it (besides the alias.host value):
Also determining whether the DoH connections are malicious becomes far easier when SSL interception is in place, this is because it allows defenders to analyse the payload that would typically be encrypted. The following screenshot shows the decrypted DoH session between the client and Cloudflare - here we are able to see the DNS request and response in the clear, which divulges the C2 domain being used, go.doh.dns-cloud.net. We can also see that the JA3 hash we previously reported was correct, as the User-Agent is Go-http-client/1.1:
The session for this DoH C2 traffic is quite large, so I am unable to show it all - this is due to the limited amount of information that can be transmitted via each DNS query. An example of data being transmitted via an A record can be seen below - the data is encrypted so won't make sense by merely viewing it:
Within this session there are hundreds of requests for the go.doh.dns-cloud.net domain with a very high variability in the FQDN seen in the name parameter of the query; this is indicative behaviour of C2 communication over DNS. Below I have merged five of the requests together in order to help demonstrate this variability:
Given the use of TCP for HTTPS vs the common use of UDP for DNS, the traffic shows as a single session in the RSA NetWitness Platform due to TCP session/port reuse, normally this type of activity would present itself over a larger number of RSA NetWitness Platform sessions when using native DNS.
RSA NetWitness Endpoint Analysis
Looking at my compromise keys, I decide to start my triage by pivoting into the Events view for the meta value, runs powershell with http argument as shown below.
From the following screenshot, we can see an executable named, googupdater.exe, running out of the users AppData directory is executing a PowerShell command to get the public IP of the endpoint. We also get to see the parameter that was passed to the googupdater.exe binary that reveals the domain being contacted:
NOTE: googupdater.exe is the goDoH binary and was renamed for dramatic effect.
We could have also pivoted on the outbound from unsigned appdata directory meta value which would have led us to this suspect binary, as well. While from an Endpoint perspective this is just another compiled tool communicating over HTTPS, the fact that it will need to spawn external processes to execute activity would lead us to an odd parent process:
Given this scenario in terms of Endpoint, this would lead us back to common hunting techniques, but in the interest of brevity, I won't dig deeper for this tool. The key items would be an uncommon parent process for some unusual activity, and the outbound connections from an unsigned tool. While both can at times be noisy, in conjunction with other drills, they can be narrowed down to cases of interest.
Conclusion
This post further substantiates the requirement for SSL interception as it vastly improves the defenders capability to investigate and triage potentially malicious communications. While it is still possible to identify suspect DoH traffic without SSL interception, it can be incredibly difficult to ascertain its intentions. DNS is also a treasure trove for defenders, and the introduction and use of DoH could vastly deplete the ability for them to protect the network effectively.
