Generally DNS exfil isn't really "stealthy". It's just that it often bypasses the controls of poorly configured networks. But DNS isn't inherently a stealthy protocol, it's something most people monitor in a corp environment, in my experience.
For production environments it's really unnecessary to allow most egress traffic, but it's especially unnecessary to allow DNS. What addresses are your servers resolving publicly? You might want DNS for service discovery but obviously that requires no public resolvers, and any DNS exfil requires public resolvers. If you do require some public DNS I'd suggest limiting it considerably in a production environment, you rarely need legitimately arbitrary public DNS access. Even for niche scenarios (like maybe a "scan this URL" service) you can isolate the DNS resolution.
For corporate environments I feel like you can just drop all TXT records. The most trivial form of DNS exfil is always via TXT. Based on the code this appears to be TXT-based as well (hence the 255 character limit, which is because TXT records encode length with a single byte).
Is there even a legitimate use for a public TXT record for corporate devices? Genuine question, I legit do not know of one but I could easily be missing something.
I monitor DNS queries made by some of my servers by setting a DoH server to systemd-resolve, some of the top queries are:
- OCSP servers to query TLS certificate validity. This is necessary because I have configured my web server to staple OCSP responses. (`e1.o.lencr.org`)
- Software repos (apt, dnf, etc). `livepatch.canonical.com` being the top contender.
- GitHub
The only place that TXT records are used in the very popular use cases would be an email server. SPF, DMARC, and DKIM all piggy back in TXT records. I would also imagine a lot of Microsoft stuff like AD use DNS .
In a corporate environment you need to block all the DNS traffic to external resolvers, except the company monitored DNS resolvers. If you have a SIEM that monitor the queries, it will be easy to identify the majority of attacks.
It's amazing how enterprises are only now doing this. Stub resolvers should not be sending queries anywhere but designated recursive resolvers for the network. It's easy to block outbound ports.
Oh, yes you should absolutely do that. What I meant is that in the case of prod you can stop all recursive DNS beyond the resolvers you own. But absolutely, all DNS should have to go through resolvers that you own.
I have done traffic analysis (e.g. netflow) and some basic base-lining/anomaly detection/cross referencing to spot this. Things like "Why do 9,999 workstations send an average of X bytes of DNS traffic a day, but yesterday Bob sent 1024 * X bytes" and "99% of DNS traffic is to a set of X DNS servers (root servers, DHCP assigned ones), but Jane almost always sends it to this one rando DNS server" get pretty easy to spot. Not perfect by any stretch, but you spot a lot of egregious stuff.
For production environments it's really unnecessary to allow most egress traffic, but it's especially unnecessary to allow DNS.
Yeah...this is really the low hanging fruit for this issue.
Filtering TXT doesn't help. Think about it. To exfiltrate data means to send data out, so you can just encode it in the query names and forget about RR types and RDATA.
Now if you were trying to infiltrate contraband, then RR types matter, but you could use A/AAAA and use as many as needed.
The way you deal with this sort of thing is by throttling query rates for domains you don't have on a list of domains known not to do this. An attacker could set up lots of domains to get around such throttling, but that's fairly expensive, and still should be noticeable. You really have to check DNS queries for odd behavior.
> Filtering TXT doesn't help. Think about it. To exfiltrate data means to send data out, so you can just encode it in the query names and forget about RR types and RDATA.
Well it definitely helps in that it would completely break this tool - as far as I know, TXT exfil is the most efficient since it allows the most data transferred per query, whereas all other forms are 1/2 as efficient or worse. But I agree there are ways around it - could you tell me more about the position that the attacker is in and how that attack works? Conceptually I can think of ways for an attacker to continue to exfil, but I'm wondering if you have something specific in mind. I'm assuming you just put the data into the subdomain, or something like that, which is much slower but still viable for C2 traffic.
Yes, it's putting the data into the name you're querying (the "qname" in DNS parlance). Say you have a message M of some length to exfiltrate, so first encode it as base64 or whatever, then break up the encoded message into chunks of 63 bytes (ASCII characters, since you encoded in base64), then send DNS lookups for ${n}.${chunk}.${some_label_identifying_exfiltration_instance}.${attacker_domain}. It doesn't matter what the replies are (NXDOMAIN is fine), or maybe you want a receipt confirmation encoded as an A or AAAA RR, whatever. You don't even need a tool because you can just script this from scratch every time you need this. The server could just log all the queries -- all you have to do is reassemble them.
One could send junk queries to these domains to try to muck with such attacks, so maybe the attacker could add a label with a MAC to every query name.
Really, this is unstoppable except via a) throttling, b) detecting this sort of thing, c) investigating detected attempts. (Or you can disallow direct DNS access to the Internet, forcing everything to go through proxies.)
The GitHub README page doesn't give many details, but for what I've seen in the (slightly blurry) screenshot, what this software does is spin up a DNS server on a given host, and then allow transferring a file to it by sending multiple DNS A requests for names containing parts of the Base64 representation of the file to that DNS server.
> Is there even a legitimate use for a public TXT record for corporate devices?
Assuming there isn't and blocking them will break applications. I realized my local resolver validates DNSSEC when I went to a place that did not forward RRSIGs, making me unable to access the Internet over there.
the problem is that most people do not monitor heavy use of TXT records; it's rather A/AAAA resolves in my experience.
but most production system i've seen allow all outgoing traffic (if poorly managed) or restrict it to port 443 (for some APIs) which is kind of all.
so if you're not in a very very restricted system (and then DNS should be restricted as well!) you'll most likely find an easy way to copy stuff over HTTPS.
Also, separately but still related to DNS fun, i enjoyed the following talk at this year's FOSDEM: "Bizarre and Unusual Uses of DNS (Rule 53: If you can think of it, someone's done it in the DNS)" https://archive.fosdem.org/2023/schedule/event/dns_bizarre_a...
It boggles my mind the fun that can be had with DNS, and also the cleverness and creativity of people out in the world!!
That's a very nice PoC but if you already control the client enough to configure its DNS you will probably also have much easier ways to exfiltrate data.
To make sure I'm tracking: the use case is setting up a dns server locally that can expose data over :53 and some other client can now get files over the dns protocol. Is that right? So this is in hope that your work's network security is not monitoring DNS traffic?
No, it's the other way round. You setup this DNS server to serve e.g. evil.com on the global internet.
Then if you can control the client, you can just do regular DNS lookups for <longstring>.evil.com, that goes to the victim's DNS server, and that DNS server forwards it to this DNS server, which saves <longstring> (many of them) to a file.
Edit: looking closer, this isn't exactly how this tool works, this DNS server assumes the client can send directly to this DNS server, I was assuming it didn't need to do that (and if it sends to the victim's DNS server instead, it's a lot harder to block). If you used it as I thought above, the output filename would just be "evil.com".
Obligatory dns tunnel software for exfil. It is super noisy if you do dns querylogging, so I'd not use it for anything major, but it is a fun research tool.
For production environments it's really unnecessary to allow most egress traffic, but it's especially unnecessary to allow DNS. What addresses are your servers resolving publicly? You might want DNS for service discovery but obviously that requires no public resolvers, and any DNS exfil requires public resolvers. If you do require some public DNS I'd suggest limiting it considerably in a production environment, you rarely need legitimately arbitrary public DNS access. Even for niche scenarios (like maybe a "scan this URL" service) you can isolate the DNS resolution.
For corporate environments I feel like you can just drop all TXT records. The most trivial form of DNS exfil is always via TXT. Based on the code this appears to be TXT-based as well (hence the 255 character limit, which is because TXT records encode length with a single byte).
Is there even a legitimate use for a public TXT record for corporate devices? Genuine question, I legit do not know of one but I could easily be missing something.