DNS Exfiltration Tool
github.com
github.com
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.
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.
Of course there are far more practical ways of going about it.
- 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 .
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.
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.
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.
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.)
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.
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!!
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".